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ABSTRACT 

Strategic  Mobility  21  (SM21)  is  a  Congressionally  mandated  and  independently  funded  applied 
research  program  through  the  Department  of  Defense  (Office  of  Naval  Research).  The  program 
is  conducted  under  the  auspices  of  the  California  State  University  -  Long  Beach  Foundation,  a 
government-industry  academic  collaborative  enterprise.  This  design  concept  supports  the  SM21 
efforts  in  developing  a  dual-use  Inland  Port  -  Multi-Modal  Terminal  Operating  System  (IP- 
MTOPS)  located  at  the  Southern  California  Logistics  Airport  in  Victorville,  California.  In  the 
context  of  the  SM2 1  program,  dual-use  technology  is  defined  as  serving  both  the  commercial 
and  military  sectors.  The  IP-MTOPS  design  concept  will  be  employed  to  define  the  technical  and 
functional  requirements  for  procuring  and  integrating  services  required  for  a  multi-modal  node 
operating  software  system  operating  within  a  Service  Oriented  Architecture.  The  design  concept 
is  the  basis  for  the  development  of  a  technical  specification,  which  will  be  jointly  developed  with 
the  Southern  California  Logistics  Airport  (SCLA)  and  the  City  of  Victorville,  California  with 
input  from  the  Department  of  Defense  (DoD).  The  design  concept  supports  the  development  of 
IP-MTOPS  within  the  framework  of  a  Service  Oriented  Architecture  (SOA).  The  IP-MTOPS 
will  be  designed  to  enable  efficient  inland  port  operations  by:  optimizing  logistics  flows; 
supporting  facility  security  requirements,  helping  to  maintain  desired  daily  facility  and 
throughput  productivity;  and  providing  high  service  quality  to  strengthen  customer  relationships. 
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1.0  Introduction 

This  design  concept  supports  the  stepwise  deployment  of  an  Inland  Port  -  Multi-Modal  Terminal 
Operating  System  (IP-MTOPS) IP-MTOPS  is  a  software  system  concept  designed  to  support 
the  facilities  and  processes  (functions)  of  a  dual-use1 2  multi-modal  inland  port  currently  under 
development  by  the  Southern  California  Logistics  Airport  (SCLA)  Authority,  the  City  of 
Victorville,  and  Strategic  Mobility  21  (SM21)3.  IP-MTOPS  will  support  the  integration  of  the 
functional  requirements  independently  developed  by  the  SCLA  Authority,  the  City  of 
Victorville,  and  SM21.  IP-MTOPS  will  support  ten  major  functions  typically  required  at  a  dual- 
use  multi-modal  distribution  node.  Since  the  SCLA  is  intended  for  dual-use,  SM21  will 
coordinate  with  Department  of  Defense  (DoD)  stakeholders  to  integrate  the  functionality 
required  to  support  the  Joint  Deployment  and  Distribution  Enterprise  (JDDE)4  with  the  required 
SCLA  commercial  functionality. 

1.1  Service  Oriented  Architecture 

It  should  be  no  surprise  that  a  review  of  existing  market  offerings  indicates  that  no  single 
commercial  software  system,  service,  or  vendor  will  meet  all  of  the  common  and  unique  SCLA 
technical  and  functional  requirements.  Therefore,  SM21  has  determined  that  a  SOA  reference 
architecture  will  be  employed  as  a  framework  for  developing  IP-MTOPS.  In  this  document, 
SOA  is  a  term  used  to  describe  an  architecture  in  which  automation  logic  is  decomposed  into 
smaller,  distinct  units  of  logic  supporting  individual  business  functions.  Collectively,  these  units 
comprise  a  larger  piece  of  business  automation  logic  and  ultimately  provide  the  capability  that 
will  be  required  for  IP-MTOPS  to  support  SCLA.  Individually,  these  units  of  logic,  or  software 
supported  services,  will  be  distributed  and  provided  by  the  operating  systems  of  the  individual 
business  operators,  such  as  BNSF  and  Cal  Cartage,  which  compose  the  SCLA.  SM21,  working 
with  SCLA,  will  determine  what  required  SCLA  functions  defined  in  this  document  are  not 
provided  by  the  distributed  business  services  to  support  the  collective  business  community. 
Based  on  the  results  of  this  joint  SCLA-SM21  analysis,  SM21  will  search  for  existing  software 
system  services  that  are  available  from  sources  outside  the  SCLA  to  fill  the  gaps.  When  the 
appropriate  existing  services  cannot  be  located,  SM2 1  and  SCLA  will  consider  development  of 
the  required  value-added  services  capable  of  closing  the  identified  gaps.  These  additional  value- 
added  services  will  be  made  available  through  IP-MTOPS. 

1.2  The  SCLA  Business  Community 

The  business  of  the  SCLA  operators  is  the  provisioning  of  logistic  services  (handling, 
management,  transport,  etc.)  for  freight  transport.  IP-MTOPS  will  support  the  cooperation 
among  the  SCLA  operators,  which  can  be  referred  to  as  the  SCLA  Cargo  Community  System. 
An  abstraction  for  such  an  environment  is  what  is  often  called  the  “Business  Community” 
concept.  A  Business  Community  is  a  set  of  Business  Operators  (enterprises)  that: 


1  The  Inland  Port  Management  Information  System  (IP-MTOPS)  will  be  jointly  developed  at  the  former  George  Air 
Force  Base,  now  the  Southern  California  Logistics  Airport  (SCLA),  to  support  SCLA  and  the  Joint  Deployment  and 
Distribution  Platform  (JDDSP).  The  JDDSP  is  defined  within  the  SM21  Initial  Capability  Document  (ICD). 

2  Dual-use  technology  serves  as  a  basis  for  both  commercial  and  military  sectors 

3  SM21  will  develop  the  military  component  of  SCLA. 

4  See  footnote  2.  The  JDDE  will  be  supported  by  the  JDDSP,  which  is  the  military  component  of  the  SCLA. 
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•  Share  a  common  market  sector  (cargo  freight  transport  into,  through,  and  out  of  SCLA) 

rr\ 

•  Hold  different  roles  on  SCLA  (like  shippers,  truck  and  rail  transport  operators,  and  3 
party  logistic  service  providers,  etc.) 

•  Have  already  existing  commercial  relations 

•  Are  coordinated  by  a  Business  Authority,  who  is  generally  an  expert  on  the  specific 
market  (like  the  SCLA  Authority) 

The  SCLA  can  take  advantage  of  the  existence  of  Business  Community  members  with  deployed 
network  services.  These  services,  integrated  through  the  IP-MTOPS  can  improve  the 
communications  between  Business  Community  Operators,  exploiting  common  trading  practices, 
and  ruling  the  community  and  communications  infrastructures  enabling  secure  transactions.  This 
target  can  be  achieved  if  the  Business  Operators  and  the  SCLA,  as  the  Business  Authority, 
participate  with  the  following  roles: 

•  The  Business  Authority  (SCLA),  supported  by  SM2 1 ,  is  in  charge  of  maintaining  the 
communication  infrastructure  that  provides  secure  communication  services,  definitions 
and  recommendations  for  application  service  implementations, 

•  Establishes,  with  support  from  SM2 1 ,  commonly  agreed  document  exchange  format  for 
transactions,  and 

•  Capitalizing  on  SCLA  and  SM21  knowledge  of  the  business  and  DoD  sector 

1.3  Functional,  Technical,  and  Service  Requirements  Overview 

This  document  provides  an  extensively  researched  list  of  the  standard  functional  and  technical 
requirements  associated  with  an  inland  multi-modal  port,  which  will  enable  analysts  to  identify 
capability  gaps  in  existing  military  and  commercial  systems  required  to  support  SCLA.  This 
document  is  ultimately  designed  to  achieve  the  following  objectives: 

•  Enable  efficient  SCLA  operations  in  support  of  commercial  and  military  shipments 
through  the  facility  by  optimizing  logistics  flows, 

•  Help  maintain  desired  individual  SCLA  productivity 

•  Maintain  high  customer  service  quality , 

•  Strengthen  customer  relationships  through  up  to  the  minute  visibility  of  shipments  and 
quick  shipment  processing  times. 

This  document  will  be  considered  a  living  document  until  it  is  formally  approved  by  a  joint 
SCLA  and  SM21  Technical  Committee.  The  document  is  organized  into  the  following  required 
functional  or  service  areas:  General  Requirements,  Inventory  Management,  Shipping  Order 
Management,  Yard  Operations,  Highway  Operations,  Rail  Operations,  Airlift  Operations, 
Warehouse  Operations,  Sealift  Planning,  Accounting,  Notifications  and  Alerts,  System  Reports, 
Integration  and  Technical  Requirements.  The  functional  areas  requiring  service  support  are 
visually  depicted  in  Figure  1. 
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Figure  1:  SCLA  Required  High-level  System  Functional  Areas 


1.4  The  Integrated  Tracking  System:  A  Supporting  Service 

The  IP-MTOPS  will  be  supported  by  another  service  proposed  for  development  by  SM21,  the 
Integrated  Tracking  System5  (ITS),  which  is  itself  composed  of  a  series  of  distributed  services 
loosely  coupled  through  a  SOA  framework.  The  ITS  will  provide  an  important  service  to  IP- 
MTOPS:  the  management  of  the  flow  of  freight  and  assets  to  and  from  the  SCLA.  The  ITS  will 
provide  track  and  trace  services  to  IP-MTOPS  and  will  be  composed  of: 

•  Existing  services  provided  by  SCLA  terminal  and  distribution  center  tenants  and 

•  “Gap-filler”  value-added  services  that  might  require  development  by  SM21  and  SCLA. 

Like  IP-MTOPS,  the  ITS  SOA  design  supports  a  stepwise  (incremental)  development  and 
deployment  effort  that  will  lead  to  the  IOC,  as  defined  in  the  Strategic  Mobility  21  -  Integrated 
Tracking  System  Analysis  and  Concept  Design  document. 


1.5  The  Strategic  Mobility  21  Collaborative  Web  Portal 

The  Collaborative  Web  Portal  will  both  be  supported  by  and  provide  services  to  IP-MTOPS  (ITS 
services  would  be  provided  through  IP-MTOPS).  The  Strategic  Mobility  21  Web  Portal  Report 
provides  the  design  for  the  Web  Portal,  which  will  provide  collaborative  planning  and  modeling 
tools  for  SCLA  and  the  Regional  Metropolitan  Planning  Offices  (MPO).  The  Web  Portal  will 
receive  its  operational  data  primarily  from  IP-MTOPS.  The  Web  Portal  Report  provides  more 
details  on  the  portal  functionality. 

1.6  SCLA  Enterprise  Architecture 

The  IP-MTOPS  is  a  major  component  of  the  overall  SCLA  Enterprise  Architecture  proposed  by 
SM21  and  depicted  in  Figure  2  below.  As  depicted,  the  IP-MTOPS  is  based  on  a  SOA  structure 
and  will  receive,  as  a  minimum,  additional  services  from  the  SM21  ITS  and  the  SM21  Web 
Portal,  which  are  also  based  on  a  SOA  architecture  model.  The  SCLA-Functions  and  required 


5  Hereafter  in  this  document  referred  to  as  the  ITS. 
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services  will  be  satisfied  primarily  through  tenant  (business  community)  owned  operating 
systems  such  as  the  BNSF  Oasis  Intermodal  Terminal  Management  System.  Paragraph  16.0 
provides  a  description  of  the  proposed  military  and  commercial  SCLA  external  system 
interfaces.  Combined,  the  SOA  structures  create  the  proposed  Enterprise  Architecture  for 
SCLA,  which  is  designed  to  enable  stakeholders  to  share  and  collaborate  in  a  distributed 
environment  without  the  need  for  a  single  user  interface. 


Strategic  Mobility  21  Enterprise  Architecture  for  SCLA 
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Figure  2:  SM21  Proposed  Enterprise  Architecture  for  SCLA 
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1.7  Strategic  Mobility  21  Background 

Strategic  Mobility  216  (SM21)  is  an  operational  level  concept  that  merges  planning  and 
execution  of  both  commercial  freight  operations  and  the  deployment  and  sustainment  of  joint 
military  forces  within  a  single  construct  of  a  Joint  Deployment  and  Distribution  Support 
Platform  (JDDSP).  Figure  1  below  provides  an  overview  of  the  SCLA  facilities  that  will  host  the 
prototype  JDDSP  and  supporting  IP-MTOPS.  As  depicted  in  the  Figure  1,  the  SCLA  will 
include  a  dual-use  multi-modal  yard  facility;  an  intermodal  yard  facility;  trans-loading 
operations;  rail  served  industrial  operations;  and  warehouses  along  with  multiple  air  cargo 
operations.  The  IP-MTOPS  will  enable  collaboration  between  these  facilities,  mode  operators, 
and  shippers  using  the  SCLA  -  both  commercial  and  military. 


Figure  3:  Southern  California  Logistics  Airport 


The  JDDSP  can  be  described  as  a  dual-use  transportation  node  that  will  be  developed  to 
seamlessly  integrate  with  and  concurrently  support  the  end-to-end  military  and  commercial 
distribution  network.  The  inland  multi-modal  port  or  transfer  facility,  a  key  component  of  the 
JDDSP,  can  be  described  as  a  central  node  on  a  dual-use  regional  agile  distribution  network. 


6  Strategic  Mobility  21  is  a  Congressionally  mandated  and  independently  funded  applied  research  program  through 
the  Office  of  Naval  Research.  The  program  is  conducted  under  the  auspices  of  the  Center  for  the  Commercial 
Deployment  of  Transportation  Technologies  (CCDOTT),  a  government-industry  academic  collaborative  enterprise. 
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Each  of  the  rail,  truck,  and  air  terminal  operations  will  employ  commercial  operating  systems 
owned  by  their  respective  companies. 

2.0  Service  Oriented  Architecture  -  Reference  Model 

As  previously  defined,  this  specification  supports  the  stepwise  deployment  of  the  IP-MTOPS 
that  will  evolve  using  a  SOA  framework.  The  SOA  concept  has  received  significant  interest 
within  the  software  design  and  development  community,  which  has  resulted  in  the  proliferation 
of  many  conflicting  definitions  of  SOA.  To  mitigate  this  problem,  the  SM21  program  has 
selected  a  SOA  reference  model  developed  by  OASIS  (Organization  for  the  Advancement  of 
Structured  Information  Standards),  a  not-for-profit,  international  consortium  that  drives  the 
development,  convergence,  and  adoption  of  e-business  standards.  Whereas  SOA  architectural 
patterns  (or  reference  architectures )  may  be  developed  to  explain  and  underpin  a  generic  design 
template  supporting  a  specific  SOA,  a  reference  model  is  intended  to  provide  an  even  higher 
level  of  commonality,  with  definitions  that  should  apply  to  all  SOA7. 

The  selected  reference  model  is  an  abstract  framework  for  understanding  significant 
relationships  among  the  entities  of  the  SCLA-JDDSP.  It  enables  the  development  of  a  specific 
architecture  using  consistent  standards  or  specifications  supporting  the  SCLA-JDDSP  Business 
Community.  For  additional  background  and  model  information,  please  refer  to  the  complete 
reference  model  documentation,  which  is  available  within  the  SM2 1  PMIS  or  at 
http://www.oasis-open.org/committees/tc  home.php?wg  abbrev=soa-rm. 

The  SM2 1  program  goal  for  using  this  reference  model  is  to  define  the  central  concepts  of 
service  oriented  architectures,  and  establish  a  vocabulary  and  a  common  understanding  of  SOA 
for  all  program  stakeholders  both  internal  and  external.  It  will  provide  a  “normative  reference” 
that  will  remain  relevant  throughout  the  SM21  SOA  stepwise  development  and  implementation, 
irrespective  of  the  many  future  technology  evolutions  that  will  influence  SOA  deployment. 

The  IP-MTOPS  architecture  will  be  developed  using  the  requirements  identified  in  this 
document.  The  SM21  supported  IP-MTOPS  Architecture  development  will  not  be  done  in 
isolation  but  will  account  for  the  goals,  motivation,  and  requirements  that  define  the  actual 
problems,  or  gaps,  being  addressed  in  both  the  commercial  and  military  sectors. 

3.0  Inland  Port  Multi-Modal  Terminal  Operating  System  (IP-MTOPS) 

The  IP-MTOPS  will  manage  the  exchange  of  structured  and  unstructured  data  provided  by 
freight  and  asset  management  software  systems  employed  for  moving  freight  into,  out  of,  and 
within  the  SCLA.  Collectively  these  external  and  internal  facility/information  systems  provide 
the  information  necessary  for  the  IP-MTOPS  to  perform  the  manipulation,  temporary  storage, 
retrieval,  transmission  and  presentation  of  actionable  information.  The  primary  IP-MTOPS 
function  is  to  provide  the  timely,  actionable  data  needed  by  decision  makers  to  manage  terminal 
and  inland  port  operations.  This  is  accomplished  through  electronically  generated  information 
reports  that  are  integrated  from  the  data  provided  by  the  various  operating  systems  within  the 
SCLA  and  that  support  freight  movement  through  the  SCLA  and  made  available  through  the 
appropriate  user  interface. 


7  Reference  Model  for  Service  Oriented  Architecture  1.0,  Public  Review  Draft  1.0,  OASIS,  10  Feb  2006,  page  4 
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The  IP-MTOPS  will  be  used  for  the  dissemination  of  actionable  information  to  individual 
terminal  personnel  and  for  automating  information  collection,  consolidation,  and  analysis  efforts 
at  the  terminal  and  provided  to  internal  and  external  SCLA-JDDSP  customers.  IP-MTOPS  will 
be  deployed  using  a  network  service  architecture  designed  to  share  information  worldwide  via 
Internet  or  Virtual  Private  Networks  (VPN).  The  IP-MTOPS  Architecture  will  support  the 
stepwise  employment  of  XML  and  Web  Service  technologies  designed  to  specifically  support 
the  SCLA-JDDSP  Business  Community  of  users. 

The  IP-MTOPS  will  be  focused  on  supporting  the  functional  management  associated  with 
controlling  the  inland  port’s  physical  operational  flow  of  transportation  assets,  cargo  and 
personnel.  The  IP-MTOPS  must  be  capable  of  supporting  the  requirements  of  both  military  and 
commercial  shippers.  The  system  will  not  only  support  the  throughput  of  shipments  via  a  single 
mode  but  must  also  support  modal  diversions  and  shipment  trans-loading  operations  for  both 
import  and  export  shipments. 

Figure  1  provides  a  visual,  high-level  depiction  of  the  required  functional  areas  that  will  be  filled 
by  multiple  information  management  systems  -  most  will  be  tenant  owned.  In  addition  to  the 
functional  areas  depicted  in  Figure  1,  which  directly  support  the  physical  flow  of  shipments 
through  the  terminal,  the  integrated  system  must  also  support  general  technical,  customer 
integration,  reporting,  administrative,  shipment  security  and  inventory  management  functions. 
These  additional  functions  are  outlined  below  and  are  provided  as  detailed  requirements  later  in 
this  document: 

•  General  Requirements  (Section  2.0)  define  how  the  commercial  operating  software 
systems  support  all  shipment  modes  in  terms  of  shipment  planning,  customer  support, 
and  industry  controls. 

•  Inventory  Management  (Section  3.0)  defines  the  requirements  that  the  commercial  multi¬ 
modal  terminal  operating  software  system  must  support  for  the  proper  management  of  the 
various  equipment  types  assigned  to  and  used  in  the  terminal.  This  includes  the 
maintenance  and  repair  of  equipment,  equipment  reservations,  and  the  wireless 
monitoring  of  equipment  used  at  the  terminal. 

•  System  Reports  (Section  13)  provides  the  requirement  to  support  both  ad-hoc  and 
customer  specific  reports  using  specific  reporting  formats  and  processes. 

•  Integration  Requirements  (Section  14.0)  is  focused  on  the  capability  to  seamlessly 
interface  with  disparate  external  systems  using  various  communication  methods  and 
message  formats. 

•  Technical  Requirements  (Section  15.0)  define  the  commercial  operating  software 
systems’  requirements  associated  with  such  topics  as  system  availability,  the  numbers 
and  types  of  transactions  that  will  need  to  be  processed,  the  types  of  technology 
components  that  need  to  interact,  and  the  access  and  security  standards. 

The  functional  areas  depicted  in  Figure  1  and  the  associations  with  the  requirements  contained  in 
this  document  are  outlined  below: 
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•  Shipment  Order  Management  (Section  4.0)  is  depicted  as  a  bar  across  the  top  of  the  four 
transportation  modes  and  linking  into  the  reporting  and  notification  requirements.  The 
commercial  multi-modal  terminal  operating  software  system  must  be  capable  of  proper 
management  and  integration  of  shipment  orders  transmitted  directly  by  the  shipper 
enterprise  resource  systems  (ERP)  or  through  the  transport  mode  operators  that  support 
the  terminal.  Customer  ERP  systems,  in  support  of  corporate  supply  chain  management 
operations,  must  be  able  to  communicate  requirements  for  modal  diversions  and  trans¬ 
loading.  This  is  critical  for  commercial  import  shipments  and  efficient  military  outbound 
force  deployments  and  sustainment  shipments. 

•  Modal  Management  (rail,  highway,  air,  and  ocean)  is  represented  by  the  individual  blue 
blocks  between  the  shipment  orders  that  control  the  use  of  a  specific  mode  and  the 
equipment/cargo  bar  that  represents  the  shipment  assets  and  cargo  transported  by  the 
individual  modes.  The  functional  requirements  that  the  commercial  operating  software 
systems  must  satisfy  to  support  each  mode  are  defined  in  Sections  6.0,  7.0,  8.0,  and  10.0. 

•  Yard  and  Ramp  Management  (Section  5.0)  includes  the  requirements  for  the  commercial 
multi-modal  terminal  operating  software  system  to  initially  set  up  and  modify,  when 
required,  the  terminal  in  terms  of  physical  layout.  The  system  must  also  support  the 
layout  and  availability  of  fixed  and  mobile  material  handling  equipment. 

•  Warehouse  Operations  (Section  9.0)  depicted  in  Figure  1  includes  the  requirements  for 
the  commercial  operating  software  systems  to  configure  warehouse  logical  zones/areas 
and  manage  the  temporary  storage  and  transfer  of  shipments.  This  functional 
requirement  area  includes  Load  Optimization  (Section  9.1) 

•  Accounting  Requirements  (Section  1 1.0)  includes  the  requirement  for  the  operating 
software  systems  to  support  the  Sarbanes-Oxley  (SOX)  controls  through  the  accounting 
processes. 

•  Notifications  and  Alerts  (Section  12.0),  which  is  represented  by  the  integrating  end  bar  in 
Figure  1,  includes  the  system  requirements  to  manage  operational  and  customer  business- 
critical  issues  and  resolve  them  early  before  they  impact  the  shipment  process.  The 
requirements  defined  in  Section  12.0  will  enable  military  and  commercial  shippers  to 
better  control  their  supply  chains  and  equipment  distribution  functions. 

Appendix  A  provides  the  information  scenarios  the  IP-MTOPS  system  is  expected  to  support. 

The  base  scenarios  include:  Ocean  Import,  Ocean  Export,  Highway  Arrival;  Highway  Departure; 
Inbound  Rail,  and  Outbound  Rail  for  both  commercial  and  military  shipments.  Additional 
requirements  to  be  provided  by  IP-MTOPS  are  expected  to  be  associated  with  Air  Cargo  arrival 
and  departure  functions. 

3.1  Application  Development  Scenario 

This  specification  supports  the  planned  approach  of  gradually  introducing  the  SCLA-JDDSP 
stakeholders  to  Web  Services.  SM21  acting  on  behalf  of  the  SCLA  local  authority  will  establish 
the  neutral,  not-for-profit  entity  needed  to  establish  and  maintain  a  Private  Universal  Description, 
Discovery,  and  Integration  (UDDI)  Registry8  for  the  SCLA-JDDSP  Business  Community  (or 
Logistics  Community  of  Practice  (LCOP)).  Further,  SM21  will  support  the  development  of  a  secure 


8  The  UDDI  specification,  currently  maintained  by  OASIS,  is  not  a  specification  for  describing  Web  services  - 
UDDI  is  simply  used  as  the  yellow  pages  of  Web  services. 
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environment  to  ensure  secure  document  and  data  interchange.  Figure  3  below  provides  an 
overview  of  the  SCLA-JDDSP  Business  Community  Service  Infrastructure  which  creates  the  IP- 


MTOPS. 


Operation  of  SM21  Business  Community  Service  Infrastructure 
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Figure  4:  Operation  of  the  SCLA-JDDSP  Business  Community  Service  Infrastructure 


The  initial  use  of  the  requirements  defined  in  this  specification  will  be  to  work  with  SCLA  to 
identify  the  current  and  future  facility  tenant  activities  and  map  their  intended  operating  systems 
against  the  requirements  in  this  document.  The  focus  of  this  will  be  to  begin  planning  both  the 
“on-boarding”  of  the  tenants’  information  systems  (data  integration  with  the  IP-MTOPS  and 
ultimately  registration  in  the  UDDI)  and  the  capability  gaps.  Capability  gaps  will  be  identified 
by  matching  the  requirements  within  this  specification  against  the  tenant  capabilities.  The  gaps 
will  be  filled  with  the  acquisition  of  additional  commercial  software  services  or  through  the 
development  of  Web  services. 

The  IP-MTOPS  application  development  is  centered  on  interfaces  that  enable  collaboration  and 
the  exploitation  of  structured  and  unstructured  data  by  techniques  such  as  data  mining.  As  noted 
above,  commercial  off-the-shelf  software  such  as  intermodal  operating  systems  and  to  some 
extent  multi-modal  operating  systems  already  provide  the  capabilities  to  produce  status 
interfaces  and  to  manage  the  workflow  at  supported  facilities.  The  IP-MTOPS  will  not  duplicate 
the  interfaces  found  in  these  commercial  products.  Instead,  through  the  use  of  this  specification 
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and  other  SM21  requirement  development  work,  the  IP-MTOPS  development  will  focus  on 
identifying  and  filling  requirement  gaps. 

As  an  example,  SM2 1  identified  a  military  capability  gap  between  ship  stow  planning,  ship  load 
sequencing  and  rail  car  load  and  movement  planning  for  force  deployments.  Planning  a  surge 
deployment  to  minimize  the  impact  on  port  operations,  while  decreasing  deployment  timelines, 
creates  the  requirement  to  sequence  the  arrival  of  rail  cars  so  that  equipment  is  delivered  to  a 
strategic  port  in  the  correct  ship  (deck  and  hold)  loading  sequence.  One  known  gap  is  that  there 
is  no  mechanism  today  to  determine  the  order  that  equipment  will  be  needed  at  the  port  to  put  it 
on  to  a  ship  to  achieve  a  particular  stow  plan.  This  is  done  manually  and  in  real  time  today, 
selecting  equipment  from  the  set  of  equipment  available  at  the  port.  Today  this  often  means 
moving  the  entire  unit  equipment  set  to  the  port  and  then  loading  potentially  one  piece  at  a  time 
instead  of  loading  the  maximum  number  of  decks  and  holds  concurrently  through  all  available 
ship  entry  points.  There  are  other  even  more  significant  issues  surrounding  coordination  with 
Class  I  railroads  but  at  this  point  it  is  sufficient  to  say  that  the  SCLA-JDDSP  will  be  able  to 
develop  Web  services  to  bridge  this  significant  capability  gap. 

3.2  Document  Development  and  Use  of  Service  Requirements  List 

The  following  paragraphs  (4.0  General  Requirements  through  17.0  Technical  Requirements)  will 
be  used  to  determine  what  services  must  be  provided  by  IP-MTOPS  to  ensure  the  SCLA 
Enterprise  Architecture  is  complete  for  dual-use  operations.  The  only  reason  for  having  IP- 
MTOPS  provide  a  specific  service  is  to  ensure  that  the  service  is  available  within  the  SCLA 
Enterprise  Architecture.  In  other  words,  if  the  service  is  available  and  accessible  by  other 
systems,  then  IP-MTOPS  does  not  need  to  provide  the  service. 

The  following  is  a  specific  example  of  how  the  list  will  be  used.  Under  General  Requirements 
(Paragraph  4.0  the  first  bullet)  there  is  a  service  requirement  to  assist  in  strategic  and  tactical 
planning  of  all  terminal  operations  and  shipments.  This  service  would  allow  SCLA  to  ensure 
that  the  facility  was  ready  for  the  ever  changing  daily  operational  environment  that  might  impact 
more  than  one  operating  entity  at  SCLA.  This  would  be  the  case  when  a  military  force  was 
deploying  through  the  SCLA  en-route  to  combat  operations  in  a  surge,  or  initial  deployment 
configuration,  requiring  basic  loads  of  ammunition  and  explosives  to  be  loaded  in  the  combat 
vehicles.  The  impact  on  SCLA  for  this  type  operation  would  be  significant  and  would  impact 
security  operations,  land  usage,  rail  and  highway  operations.  How  this  service  is  provided  by  or 
through  IP-MTOPS  would  be  resolved  during  the  joint  SCLA-SM21  enterprise  architecture 
development  process. 

As  an  initial  step  in  the  development  of  this  document,  an  exhaustive  literature  search  was 
conducted  to  review  the  functions,  processes,  and  procedures  associated  with  multi-modal 
terminals  including  both  existing  and  future  terminal  designs.  The  list  of  references  included  in 
the  final  development  of  this  document  is  provided  in  Appendix  C.  In  addition  to  the  use  of 
outside  references,  the  extensive  experience  of  the  project  team  members  with  the  direct 
development  of  terminal  operating  systems  greatly  enhanced  the  final  product. 

The  dual-use  SCLA-JDDSP  physical  facility  design  includes  hardware,  software,  and 
infrastructure  components  to  provide  the  required  military  and  commercial  services.  These 
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services  and  designs  are  provided  in  the  series  of  deliverables  issued  from  2004  through  June 
2007.  The  references  are  contained  in  Appendix  C.9 

The  following  sections  provide  the  multi-modal  terminal  operating  system  functional 
requirements  that  must  be  supported  by  services  that  were  identified  to  support  the  SM  2 1 
program  and  the  development  of  the  JDDSP  multi-modal  terminal. 

4.0  General  Service  Requirements 

The  general  service  requirements  associated  with  the  SCLA  Enterprise  Architecture  to  enable  a 
comprehensive,  integrated  web-enabled  solution  to  support  SCLA  air,  ocean,  rail,  and  highway 
operations.  This  includes  the  management  of  freight,  military  air  passengers,  inland  port 
infrastructure,  business  processes,  and  transportation  assets. 

The  individual  general  service  requirements  are  provided  below: 

•  Assist  in  strategic  and  tactical  planning  of  all  terminal  operations  and  shipments. 

•  Provide  visibility  to  management,  operating  personnel,  customers  and  business  partners, 
including  alerts  for  out  of  plan  or  near-out  of  plan  events. 

•  Track  and  control  all  cargo  and  terminal  assets  (personnel,  equipment,  and  land). 

•  Ability  to  affiliate  DoD  Transportation  Control  Numbers  (TCN)  with  commercial 
shipment  data 

•  Must  be  able  to  capture  and  store  shipment  status  events  across  transportation  modes  for 
full  end-to-end  shipment  visibility. 

•  Ability  to  maintain  and  track  service/  operations  issues  via  on-line  Problem  Log. 

•  Provide  flexible  external  communication  for  inbound  and  outbound  shipment  flows 
across  multiple  transportation  modes. 

•  Provide  searchable  audit  trails  are  required  for  critical  transactions. 

•  Must  record  date,  time  and  source  stamps  on  all  electronic  status  update  transactions. 

•  Must  comply  with  industry  Sarbanes-Oxley  (SOX)  controls. 

•  Must  support  any  Homeland  security  requirements  for  international  container  terminals. 

•  Report  on  and  support  HAZMAT  compatibility  across  all  modes. 

•  Support  the  Mission  concept  for  tracking  cargo  passing  through  the  terminal. 

•  Ability  to  plan,  in  advance,  containers  directly  from  one  mode  to  another. 

•  Ability  to  support  multiple  languages  and  currency  for  external  communications. 

•  Provide  terminal  managers  the  ability  to  view  and  create  custom  dashboards  that  contain 
terminal-wide  performance  indicators,  such  as  train  performance,  yard  utilization,  and 
truck  turn  times. 

•  Ability  to  dispatch  Work  Orders  to  yard  personnel  using  radio  data  terminals  (RDTs)  to 
efficiently  manage  operations  and  monitor  progress  in  real-time. 


9  While  service-orientation  is  a  concept  found  in  a  broad  variety  of  applications,  this  document  focuses  on  the  field 
of  software  architecture  for  the  IP-MTOPS.  The  concepts  and  relationships  described  may  apply  to  other  "service" 
environments;  however,  this  specification  does  not  completely  account  for  design  requirements  outside  of  the 
software  domain. 
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•  Must  be  able  to  manage  en-route,  arrived  and  departed  shipments  and  its  cargo  wirelessly 
from  RDTs  or  handheld/  tablet  devices. 

•  Ability  to  create  terminal  metrics  definitions  to  match  performance  measurement 
objectives  for  air,  vessel,  crane,  rail,  MHE  (Material  Handling  Equipment),  yard,  and 
gate,  including  rail  gross  and  net  productivity,  ETC,  delay,  yard  utilization,  truck  turn 
time,  number  of  trouble  transactions  and  MHE  productivity. 

•  Provide  a  graphical  view  of  terminal/  warehouse  layout  and  operations  with  configurable 
color  palettes  and  filtering  and  provide  instant  information  pop-ups. 

•  Provide  an  interactive  dashboard  of  electronic  errors  by  reject  reason/  message  set/ 
trading  partner/  location. 

•  Ability  to  the  handle,  alert  and  correct  of  out-of-sequence  events  and  rejections. 

•  Must  distinguish  events  in  multiple  time  zones. 

•  Support  multi-currency  and  unit  of  measure  (UOM)  conversions. 

•  Monitors  activities  with  respect  to  user  defined  service  levels. 

•  Ability  to  support  spell  check  function  on  all  free-form  text  fields. 

•  Must  provide  online  context  sensitive  Help  and  customization  at  field  level. 

•  Highly  configurable  and  business  rule  driven. 

•  Apply  business  variable  rules  for  archiving/  purging  equipment  history. 

5.0  Inventory  Management 

•  Must  be  able  to  store  and  manage  an  inventory  of  various  equipment  types  at  multiple 
locations  to  support  local,  national  and  global  activities. 

•  Must  capture  status  events  from  air,  ocean,  rail  and  truck  transportation  modes  through 
manual  and  electronic  formats  in  near  real-time  response. 

•  Ability  to  view  all  status  messages  from  various  sources  on  equipment  to  include 
estimated  time  of  next  key  event. 

•  Ability  to  view  all  terminal  flows,  past  and  pending  actions  and  events  performed  on  the 
equipment  such  as  movement  and  storage  history,  associations,  mechanical  data  updates, 
waybill  changes  and  applied  charges. 

•  Ability  to  easily  access  all  associated  data  relevant  to  an  inventory  item  such  as  pick-up 
numbers,  origin  and  destination  city  site  and  rail  ramp  codes,  notify  party  information, 
container  size,  gross  weight  and  HAZMAT  details. 

•  Provide  the  ability  to  display  dashboard  views  of  inventories  including:  units  picked  up 
and  en-route,  units  received  at  destination,  units  dropped  off,  units  available. 

•  Ability  to  review  the  equipment  manifest  down  to  the  line  item  whether  transporting 
serial  or  bulk  cargo. 

•  Provide  the  ability  to  archive  equipment  inventory  levels  to  support  trend  analysis. 

•  Ability  to  provide  statistics  regarding  the  current  and  historical  state  of  the  inventory  and 
available  storage  locations. 

•  Provide  the  ability  to  attach  and  easily  retrieve  scanned  documents  and  notes  associated 
with  a  particular  piece  of  equipment  and  other  portable  equipment  such  as  gensets. 

•  Provide  the  capability  to  add  equipment  to  the  system;  update  equipment  specifications; 
delete  equipment  from  system  if  permanently  removed  due  to  damage  etc.;  ability  to  add 
or  update  based  on  single  equipment  number  or  range  of  numbers. 
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•  Capability  to  view  and  manage  equipment  associations  (e.g.  container  to  chassis, 
container  to  railcar  and  chassis  bundles). 

•  Automatically  create  system  generated  holds  and  permissions  based  on  configurable 
business  rules  such  as  restricted  or  prohibited  commodities,  mechanical  holds  (based  on 
equipment  type  or  condition),  Homeland  Security,  U.S.  Customs  or  routing. 

•  Provide  access  to  inventory  information  including  available,  reserved,  on-hold,  customs 
and  bad  order  equipment. 

•  For  railcars,  provide  the  ability  to  capture  and  update  specification  data  by  range  of  car 
numbers  and  single  car  number.  Data  should  include:  physical  characteristics  including 
ATR  (distance  to  top  of  rail  to  lowest  part  of  car)  and  center  of  gravity;  American 
Association  of  Railroads  (AAR)  type,  loading  capabilities  average  by  car  and  well; 
owner;  build  date;  manufacturer  name,  address  and  contact;  date  placed  online;  cost; 
daily  car  hire  rate;  hitch  configuration;  stacking  capacity. 

•  For  aircraft,  provide  the  ability  to  capture  and  update  specification  data  by  tail  number 
range  and  single  tail  number.  Data  should  include:  physical  characteristics;  class  type, 
loading  capabilities;  payload  limits;  owner;  build  date;  manufacturer  name,  address  and 
contact;  date  placed  online;  cost. 

•  For  containers,  trailers  and  chassis,  provide  the  ability  to  capture  and  update  specification 
data  by  range  of  equipment  numbers  and  single  equipment  number.  Data  should  include: 
physical  characteristics;  type,  tare  weight;  grade;  owner;  build  date;  manufacturer  name, 
address  and  contact;  date  placed  online;  cost;  state  registration  information  (for  over-the- 
road  equipment);  license  plate  number. 

•  Maintain  a  central  repository  of  information  for  all  owned  and  leased  equipment  acquired 
through  any  source. 

•  Must  be  able  to  manage  fleet  contracts  and  leases  for  all  types  of  equipment. 

•  Must  be  able  to  identify  in  the  system  that  operates  and  owns  the  equipment. 

•  Must  be  able  to  monitor  regulatory  compliance  for  each  equipment  type. 

•  Ability  to  assign  equipment  to  a  designated  pool  or  location. 

•  Provide  the  ability  to  flag  equipment  for  restricted  use  (i.e.  long-haul). 

•  Must  be  able  to  show  available  equipment  by  location  in  near  real-time. 

•  Provide  modeling  tools  for  strategic  equipment  fleet  sizing  decisions.  Key  decision 
criteria  are  equipment  utilization,  fleet  size,  loadings,  transit  times,  equipment  cycle 
times,  and  equipment  costs. 

•  Ability  to  display  third  party  lost  or  destroyed  equipment  cost  recovery  information 
including  third  party  billed,  loss  type  code,  amount  billed,  amount  collected,  comments 
field 

•  Provide  the  ability  to  flag  equipment  for  sale  (mass  update)  based  on  user  selected 
criteria. 

•  Ability  to  support  lease  contract  information  on-line  (using  imaging  or  softcopy 
versions). 

•  Optimize  the  number  of  days  facility  owned  containers,  trailers  and  chassis  are  under  the 
control  of  customers,  truckers,  rail  carriers  and  partners  by  providing  online  displays  and 
reports  required  to  support  management  efforts  to  facilitate  the  return  of  owned 
equipment. 


13 


Multi-Modal  Terminal  Operating  Software  System 


•  Ability  to  capture  and  manage  lease  contracts/  agreements  online  including  key 
information  such  as  (contract  termination,  age,  manufacturer,  etc.) 

•  Ability  to  image  and  link  new  addendums  or  riders  to  existing  lease  contract  must  be  able 
link  multiple  addendums  or  riders  to  a  single  contact  and  maintain  a  chronological  order. 

•  Ability  to  image  all  lease  contracts  and  view  on-line  by  contract  or  equipment  number. 

•  Ability  to  exchange  information  automatically  (electronically)  to  and  from  the  leasing 
companies,  i.e.  changes  to  equipment  information  (on-hire  and  off-hire) 

•  Ability  to  apply  mass  changes  to  equipment  records  based  on  changes  to  one  or  more 
contracts  (i.e.  change  the  lease  end  date  for  all  equipment  on  the  following  five 
contracts). 

•  Provide  the  ability  to  report  miles  by  car  by  state  to  leasing  agent. 

•  Must  be  able  to  track/  apply  Mileage  Credits. 

•  Plan  and  manage  the  on-hire  and  off-hire  of  leased  assets,  and  disposal  of  lost  or 
damaged  equipment. 

5.1  Maintenance  and  Repair  (M&R) 

•  The  system  must  accept  and  confirm  the  receipt  vendor  invoice  submissions 
electronically  or  through  a  web-form. 

•  The  system  must  validate  the  vendor’s  contract  expiration  date  as  part  of  the  invoice 
review  process  and  support  contracts  without  expirations. 

•  The  system  must  be  able  to  differentiate  between  an  original  invoice  and  subsequent 
revisions  to  the  invoice. 

•  Must  exhibit  all  necessary  SOX  controls  for  the  invoice  process. 

•  Systematically  apply  validations  and  edits  to  defined  fields  against  a  common  authorized 
materials  table  at  the  line-item  level  of  detail  and  apply  logic  based  on  user  configurable 
business  rules  such  reject  any  invoice  that  exceeds  the  purchase  order  amount. 

•  The  system  must  allow  the  ability  to  decline  a  repair  invoice  in  its  entirety  or  at  the  line 
item  level. 

•  Maintain  authorized  vendor  AAR  Job  code/  Why  Made  code  combinations. 

•  Provide  analysis  of  repairs  performed  by  damage  type,  cost,  equipment  type,  location 
(including  city/  site),  material,  vendor,  accounts  payable  exception 

•  Provide  the  ability  to  store  and  retrieve  digital  photos  of  damage. 

•  The  system  must  validate  authorized  repair  status  against  the  list  of  Do  Not  Repair 
(DNR)  equipment. 

•  Provide  the  ability  to  review  and  update  equipment  condition  to  flag  damage  severity  and 
inspection. 

•  The  ability  to  flag  equipment  to  be  taken  out  of  service,  to  schedule  annual  maintenance 
and  notify  operations  as  well  as  other  interested  parties. 

•  Provide  the  ability  to  keep  internal  mileage  tables  up  to  date  and  make  sure  miles  are 
assigned  to  routes  based  on  carrier  distances  for  each  leg. 

•  The  system  must  support  uploading  AAR  authorized  materials  tables  and  (Universal 
Machine  Language  Equipment  Register)  UMLER  railcar  data. 

•  Capability  to  report  equipment  additions,  number  changes  including  mechanical 
specification  data  to  the  AAR. 
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5.2  Reservations 

•  Provide  a  detailed  audit  trail  of  all  reservation  activity  by  user  for  reservations  made, 
changed,  canceled,  etc. 

•  Provide  the  ability  to  reserve  equipment  by  characteristics  such  as  size,  type,  and  grade  or 
by  a  specific  number. 

•  The  system  must  confirm  receipt  of  reservations  to  the  customer  via  an  email 
confirmation  option  in  the  customer  profile. 

•  View  electronic  reservations  submitted  by  customer,  date  or  container  number. 

•  Must  provide  the  ability  to  view,  add,  update  and  cancel  an  order. 

•  Must  be  able  to  tie  one  reservation  to  many  equipment  records. 

•  Allow  or  prevent  specific  units  or  groups  of  equipment  targeted  to  specific  destination 
based  on  configurable  rules. 

•  The  system  must  support  assignment  of  reservations  to  a  Wait  List  category  and  maintain 
visibility  until  capacity  becomes  available. 

•  When  reservations  expire,  containers  are  unreserved  in  the  system  to  make  them 
available  for  another  customer. 

•  Ability  to  add  user  notes  to  a  reservation. 

•  Ability  to  track  and  charge  customers  for  reservations  not  picked  up. 

•  Ability  for  operations  to  monitor  a  unit  picked  up  against  a  reservation  including  trucker 
ID  (SCAC  code)  and  trucker  name. 

•  Access  to  inventory  information  including  available,  bad  order  equipment,  reserved 
equipment  including  the  customer  reserving  the  container  and  the  date  of  reservation,  per 
diem  rates  and  reservation  charges. 

•  Ability  to  allocate  containers  that  have  been  in  the  yard  the  longest  using  the  in-gate  date. 

•  Ability  to  substitute  equipment  inventory  of  another  size  in  cases  where  there  is  a 
shortage  of  one  equipment  size  and/or  a  surplus  in  certain  equipment  size/types. 

5.3  Wireless  Monitoring 

•  Must  be  able  to  integrate  with  major  Global  Positioning  System  (GPS)  vendors  for 
satellite  tracking  of  yard  equipment  (i.e.  MHE),  railcars  and  containers. 

•  Must  be  able  to  configure  telemetry  devices  over  the  internet. 

•  Ability  to  monitor  reefer  temperature,  vent,  humidity,  oxygen,  and  carbon  dioxide 
information. 

•  Must  have  alerting  on  user  defined  events  and  thresholds  (e.g.  temperature  +/-  10  degrees 
for  more  than  15  minutes  for  temperature  sensitive  cargo). 

•  Provide  the  ability  to  interrogate  electronic  door  seals  and  Radio  Frequency  Identification 
(RFID)  tags  on  equipment  to  allow  for  terminal  personnel  to  maintain  wheeled  and 
grounded  container  inventories  in  the  yard,  in  real-time  with  ruggedized  RDTs  and 
wireless  hand  held  devices. 

•  Must  be  able  to  employ  readers  capable  of  interrogating  all  passive  and  active  tracking 
tags 

6.0  Shipment  Order  Management 

•  Must  be  able  to  electronically  tender  an  order  to  multiple  carriers  over  multiple  modes  of 
transport  (e.g.  e-mail,  EDI,  fax). 
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•  Must  be  able  to  accommodate  international  origin  and  destination  locations  as  well  as 
multiple  currency  amounts. 

•  Must  have  ability  to  systematically  apply  validations  and  edits  to  defined  fields  during 
waybill  information  entry. 

•  Ability  to  view  electronic  shipping  order  messages  by  customer,  date  or  container 
number  as  when  the  equipment  was  billed;  submitted  and  accepted  by  the  carrier. 

•  Ability  to  automatically  or  manually  retransmit  shipment  orders  to  carriers  and  any  other 
required  party. 

•  The  ability  to  print/  FAX  a  shipping  order  in  a  standard  format  to  send  to  the  carriers. 

•  Ability  to  create  and  organize  templates  for  ease  of  standardizing  and  generating 
shipment  orders. 

•  Ability  to  maintain  customer  profiles  detailing  key  contacts,  addresses,  notes,  preference 
of  notifications  and  authorized  order  templates. 

•  Must  be  able  to  store  data  for  a  shipment  that  is  not  scheduled  to  move  for  several  weeks 
or  more  in  the  future. 

•  Ability  to  do  a  mass  tender  of  equipment  to  a  carrier  (pool  dispatch). 

•  Support  one-way  contract  details  including:  origin  and  destination;  pick-up  volumes  and 
time  information  at  origin  and  destination;  repositioning  rates;  free  time  allowed;  per 
diem  rates  to  apply  after  free  time. 

•  The  ability  to  transload  equipment  on  orders,  updating  equipment  status  with  the  billing 
of  new  container  on  same  order. 

•  Ability  to  automatically  accept  HAZMAT  orders  electronically  and  control  by  the 
customer  profile. 

•  The  ability  to  update  an  order  for  Service  Recovery,  giving  visibility  to  operations  of  the 
change,  but  keeping  the  same  rate  quote  to  the  customer. 

•  Provide  diversion  information  to  all  involved  parties  via  system  alert  to  selected  users. 

•  Provide  a  system  generated  order  hold  based  on  established  requirements  such  as 
restricted  or  prohibited  commodities,  mechanical  holds,  routing,  Homeland  Security  and 
U.S.  Customs. 

•  Ability  to  automatically  reject  an  order  based  on  equipment,  commodity  and  location 
rules. 

•  The  ability  to  assign  and  control  priority  of  orders  based  on  configurable  rules. 

•  Ability  to  support  and  monitor  priority  customers/  accounts/  shipping  orders. 

•  Must  be  able  to  track  shipments  in  the  system  based  on  various  reference  numbers  and 
attributes  such  as  Equipment  Number,  Shipper,  Shipper  Reference,  Origin,  Destination, 
Notify  Party,  Beneficial  Cargo  Owner,  Status,  and  Priority. 

•  The  ability  to  view  and  report  on  full  Routing  information. 

•  Automatic  generation  of  dray  orders  related  to  the  applicable  Route. 

•  The  ability  to  view  and  report  on  the  current  and  historic  status  of  a  shipping  order 
including  all  modifications/corrections,  routing  information,  revenue  and  cost 
information,  invoice  status  and  notes  (aircraft,  vessel,  train,  railcar  and  container  level) 
and  pick-up  numbers. 

•  Access  to  the  details  and  current  status  of  each  equipment  associated  with  an  order. 

•  The  ability  to  enter  and  view  all  notes  pertinent  to  a  shipping  order. 
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•  Ability  to  include  special  instructions  on  shipment  orders  such  as  Customs,  hazardous, 
protective  service,  overweight  and  oversized. 

•  Must  be  able  to  capture  and  store  imaged  Bill  of  Landing  (BOL)  document  and  associate 
with  a  shipment. 

•  Must  be  able  to  capture  and  store  imaged  Port  of  Discharge  (POD)  documents  and 
associate  with  a  shipment. 

•  Ability  to  view  and  update  U.S.  Customs  information. 

•  Ability  to  set  up  multiple  legs  with  the  same  origin  and  destination  and  to  distinguish 
between  different  criteria:  vendor,  priority,  mode,  mode  of  transport. 

•  Support  both  Rule  1 1  and  non-rule  1 1  shipment  orders. 

•  The  ability  to  flag  special/  priority  services  on  a  shipping  order  and  provide  alerts  when 
the  terminal  did  not  meet  the  service  agreement  in  order  to  make  adjustment  prior  to 
generating  the  customer  invoice  (assessorial  charges). 

•  Ability  to  automatically  close  shipment  order  upon  configurable  termination  rules. 

7.0  Yard  Operations 

•  Must  have  a  means  to  initially  set  up  the  terminal  in  terms  of  physical  layout,  and 
available  MHEs. 

•  System  must  permit  frequent  modifications  to  the  terminal  layout  and  inform  personnel. 

•  System  must  allow  for  permanent  modifications  (yard  expansion,  acquisition  of 
additional  MHEs,  etc.) 

•  System  must  allow  for  temporary  changes  (out  of  order  equipment,  unavailable  area  of 
the  yard  due  to  weather,  repaving,  security,  contamination,  etc.). 

•  Ability  to  provide  a  graphical  view  of  the  physical  location  of  the  inventory. 

•  Ability  to  provide  a  graphical  view  of  terminal  activity. 

•  Support  both  stacked  and  wheeled  storage. 

•  Support  reefer  areas  and  accommodate  HAZMAT  compatibility. 

•  System  must  have  the  means  to  set  up  parking  and  stacking  rules  throughout  the  terminal 
(tactical  and  strategic  rules). 

•  System  will  recommend  storage  locations  minimizing  the  mixing  of  stacks  and  rehandles; 
will  automatically  assign  containers  to  optimal  positions  across  the  yard,  maintaining 
compliance  with  hazardous  container  segregation  rules,  ensuring  proximity  to  the 
scheduled  loading  berth,  aircraft  or  rail  track,  and  distributing  for  efficient  MHE 
operations. 

•  Visibility  to  the  current  expected  train,  vessel  or  aircraft  arrival  and  current  expected  time 
of  grounding  for  in-transit  orders. 

•  Ability  to  manage  shift  crews  and  schedules  for  various  terminal  activities. 

•  System  will  have  the  capability  to  optimize  work  assignments  based  on  yard  and 
equipment  constraints,  and  operating  rules  such  as  target  moves  per  hour. 

•  Ability  to  derive  shipment  order  information  and  automatically  plan /  apply  to  terminal 
activity. 

•  Perform  a  single  transaction  to  create  multiple  activities. 

•  Perform  a  single  transaction  for  multiple  units. 

•  Must  be  able  to  capture  yard  location  of  any  equipment  dropped  at  the  terminal. 

•  Must  be  able  to  search  and  report  on  equipment  inventory,  status  and  location. 
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•  Ability  for  terminal  to  report  summary  and  detail  data  for  each  wheeled  slot,  each 
grounded  stack,  each  track,  each  runway,  the  shop,  slots  used,  slots  available. 

•  Provide  visibility  of  local  movement,  assignments  and  schedule  of  all  equipment  in  the 
yard. 

•  Provide  real-time  status  messages  of  all  yard  activities  to  designated  parties. 

•  Provide  comprehensive  real-time  monitoring  of  the  operation  as  well  as  comprehensive 
statistical  performance  reporting  for  management. 

•  Maintains  a  full  inventory  of  MHEs  and  support  equipment  and  maintenance  history. 

•  Management  of  ground  handling  documents  other  than  waybills. 

•  Must  be  compatible  with  RF  technology  standards;  support  data  acquisition  from 
stationary  and  hand  held  readers. 

•  Ability  to  efficiently  track  on  terminal  storage  information/  issues  that  occur  in  the 
terminal  yard  after  notification,  but  prior  to  the  equipment  being  out  gated  that  may 
impact  the  per  diem  free  day  calculation. 

8.0  Highway  Gate  Operations 

•  Must  support  processing  orders,  performing  dispatch  functions,  managing  equipment  and 
drivers,  managing  critical  document  images  and  providing  back-office  financial 
information  for  various  types  of  equipment  received  at  the  gate. 

•  Visibility  to  the  equipment  in-gate  and  out-gate  activity  including  trucker  information. 

•  Ability  to  interface  with  dray  carriers  to  provide  visibly  of  cargo  movement. 

•  Provide  the  capability  for  appointment  scheduling  at  the  gate  which  will  allow  a  high 
quality  data  for  planning  operations  by  providing  visibility  to  freight  arriving  at  the 
terminal  to  eliminate  data  entry  errors  or  trouble  transactions. 

•  Provide  real-time  status  messages  of  gate  activities  to  designated  parties. 

•  Provide  gate  security  measures  and  controls  by  capturing  relevant  data  and  image  inputs 
and  warn  of  any  shipment  holds  or  interchange  issues. 

•  Provide  an  inspection  process  for  arriving  and  departing  equipment. 

•  Ability  to  tie  each  out-gate  container  to  each  reservation  for  tracking  purposes. 

•  Provide  electronic  information  exchange  with  UIIA  to  ensure  trucker  has  a  relationship 
with  terminal,  and  if  the  trucker  does  snot,  provide  alerts  or  prevent  the  transactions  from 
completing. 

•  Provide  the  ability  to  suspend  a  trucker’s  interchange  agreement. 

•  Provide  the  ability  to  ban  a  truck/  driver  from  the  terminal. 

•  Manage  staging  area  for  drivers  and  their  equipment  as  they  wait  for  the  proper  staging 
of  the  equipment  requested. 

•  Match  up  cargo  and  equipment  with  records  of  expected  arrivals  from  advanced  orders. 

•  Processes  containers,  chassis,  trailers  and  other  cargo  that  arrive  at  the  gate. 

•  Recommend  placement  location  information,  including  park-or-stack  decisions. 

•  Process  outbound  gate  requests  for  containers,  chassis,  trailers  and  other  cargo  that  will 
leave  by  the  gate. 

•  Controls  must  exist  to  assure  that  the  container  is  released  to  the  trucker  representing  the 
customer  with  the  valid  reservation. 

•  Match  up  and  record  gate  departure  events  with  trucker  arrivals. 
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•  Provide  instructions/  work  orders  for  placement  of  cargo  in  the  terminal  as  well  as  work 
orders  needed  to  retrieve  cargo. 

•  Determine  immediate  equipment  needs,  such  as  a  chassis  for  yard  operations. 

•  Ability  to  assign  and  dispatch  moves  and  open  Dray  Orders  to  the  truckers  by:  container 
number,  ramp  pairs,  train  id,  car  number,  availability  and  locations. 

•  Provide  visibility  to  missed  cross-towns. 

•  Support  the  capability  to  enable  authorized  truckers  and  partners  to  update  information 
and /  or  review  out-gate  equipment  and  submit  dispute  documentation. 

•  Integrate  with  automated  gates,  RFID  and  optical  character  camera  technology. 

•  Provide  ability  for  personal  to  wirelessly  manage  gate  operations  from  ruggedized  tablets 
and  handheld  devices. 

9.0  Rail  Operations 

•  Ability  to  conduct  empty  rail  car  distribution  and  optimization  to  efficiently  allocate  cars 
to  meet  requirements 

•  Maintains  inbound  and  outbound  train  profiles  which  captures  various  details  including 
any  route  restrictions. 

•  Maintains  scheduling  information  (considers  schedule  of  the  integrated  system). 

•  Creates,  modifies,  deletes  and  reinstates  seasonal  and  operational  schedules. 

•  Ability  to  interface  with  rail  carriers  to  provide  visibly  of  cargo  movement. 

•  Ability  to  receive  inbound  consists  and  generate  outbound  consists  electronically  with 
designated  rail  carriers. 

•  Ability  to  monitor  trains  in  transit,  using  CLM  information,  by  planned  and  actual  times 
for  the  following  information;  way  points,  pickups,  arrival  at  destination,  cargo 
availability  times. 

•  Ability  to  track  actual  train  performance  to  schedule  and  time  variance  using  CLMs, 
including:  containers,  car  and  train  segments  in-transit,  off-schedule  cars  and  train 
segments  in-transit. 

•  Ability  for  the  system  to  discount  bad  order  railcars  from  usage. 

•  Ability  to  track  cars  and  trains  in-transit,  late  cars  and  train  segments  and  cars  with 
mechanical  problems. 

•  Ability  for  the  user  to  add  notes  for  various  levels  of  a  train  such  as  train  ID  block, 
railcar,  well,  container. 

•  Provide  equipment  and  order  information  on  en-route  and  arrived  inbound  train  consists. 

•  Match  actual  arrivals  versus  planned  and  allows  for  manually  entered  equipment  and 
automated  updates. 

•  Ability  to  add  railcars  not  updated  as  arrived  to  a  track. 

•  Process  containers,  chassis,  trailers  and  other  cargo  that  arrives  on  an  inbound  train. 

•  Notifies  customers  based  on  profiles  of  cargo  arrival  and  availability. 

•  Provide  internal  triggers  for  activities  related  to  the  arrival  and  departure  to  update  train 
status  and  equipment  action  (stay-up,  transload,  ground,  etc.). 

•  Provide  internal  triggers  for  activities  related  to  train  spotting  and  discharge  (Rail,  car  and 
container  level). 

•  Allocates  MHE  and  crews  for  dropping  inbound  and  building  outbound  trains. 

•  Create  work  orders  for  unloading  (or  trans-loading)  operations. 
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•  Determine  immediate  equipment  grounding  needs,  such  as  a  chassis. 

•  Recommend  placement  location  information,  including  park-or-stack  decisions. 

•  Provide  instructions/  work  orders  for  placement  of  cargo  in  the  terminal. 

•  Ability  for  the  user  to  add  notes  to  trains,  capturing  the  status  at  the  time  the  note  was 
taken. 

•  Provide  internal  triggers  to  support  the  unlinking  of  railcars  from  the  train,  and  equipment 
from  the  railcars. 

•  Perform  inspection  of  inbound  and  outbound  equipment  and  cargo  (same  as  at  gate). 

•  Ability  for  users  to  select  and  view  the  details  of  an  inbound  train  and  reallocate  by  block 
or  railcar  to  another  train. 

•  Provide  the  ability  to  reserve  railcar  slots  for  customers,  products,  agreements  or  line  of 
business. 

•  Recommends  an  outbound  train  plan  which  can  be  updated  based  upon  configurable 
business  rules,  train  profiles  and  available  equipment. 

•  Creates  work  orders  for  loading  the  outbound  train. 

•  Create  works  orders  as  needed  to  retrieve  cargo. 

•  Ability  plan  trains  based  on:  vessel  voyage  ID,  train  ID,  destination  blocks,  train  length, 
gross  weight,  commodity,  customer  and  mixed  destination  cars. 

•  Ability  for  the  user  to  assign  railcars  to  a  train/  block. 

•  Ability  for  the  user  to  pre-block  railcars  to  a  destination. 

•  Ability  to  plan  an  outbound  train  based  upon  a  vessel  stowage  plan. 

•  Optimize  loading  and  discharging  by  matching  the  next  discharge  point  of  a  container 
with  the  block  destination. 

•  Ability  to  view  what  is  loaded  on  a  train  including  planned  moves. 

•  Provide  graphical  railcar  sequence  planning  and  train  scheduling. 

•  Ability  to  support  compressive  load  and  blocking  rules  with  screen  warnings. 

•  Determine  percentage  of  car  utilization  for  each  outbound  consist. 

•  Ability  to  view  Load  vs.  Capacity  for  a  train  (real-time),  allowing  updates  to  ensure 
utilization  against  plan. 

•  Provide  rail  security  measures  and  controls  by  warning  of  any  shipment  holds  or 
interchange  issues. 

•  The  system  must  support  railroad  pickup  numbers  (railroads  unique  number  to  provide 
security  in  the  movement  of  equipment  out  of  their  facility). 

•  Ability  to  indicate  that  that  the  loading  of  an  outbound  consist  has  been  confirmed  and 
secured. 

•  Ability  for  the  system  to  recognize  and  record  warnings/  errors  as  a  result  of  confirmed 
loads  record  in  the  system  (i.e.  violation  of  loading  rules). 

•  Provide  ability  identify  and  track  reasons  for  unused  railcar  slots  and  apply  notes  to 
outbound  train. 

•  Ability  to  create  and  maintain  a  track  list  of  railcars  at  the  terminal  tracks  (en-route  or 
available). 

•  Ability  to  select  a  site  track  and  assign  or  reassign  a  railcar  to  the  track,  in  a  track 
position,  using  a  drag  and  drop  method. 
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•  Ability  to  view  existing  railcars  already  spotted  and  assigned  to  other  trains  on  the  track, 
and  the  associated  status  of  each  railcar,  and  ability  to  compare  cars  on  track  with 
spotting  instructions. 

•  Ability  to  view  departed  trains  by  destination  block,  train  consist,  container  size,  weight, 
destination  and  shippers. 

•  Ability  to  auto-sequence  cars  (modify  railcar  standing  order)  after  loading  function  is 
complete. 

•  Must  be  able  to  create  a  yard  switch  list  once  equipment  has  been  moved  in  system. 

•  Ability  to  order  railcars  for  a  ramp,  either  by  railcar  type  or  quantity  of  wells. 

•  Ability  for  the  user  to  add  power  units  and  applied  horsepower  of  each  train. 

•  Ability  for  the  system  to  calculate  total  horsepower,  power  to  weight  ratio,  and  apply 
minimum  rules  associated  with  power  and  train  length. 

•  Must  be  able  to  produce  a  BOL  if  required  and  electronically  send  to  designated  parties. 

•  Print  rail  waybills  in  the  (Association  of  American  Railroads)  AAR  standard  format. 

•  Ability  to  determine  the  actual  ramps  that  correspond  to  any  route  O/D  pair. 

•  Ability  to  set  up  generic  routes,  or  to  restrict  routes  to  certain  shippers,  beneficial  owners, 
lines  of  business,  agreements,  equipment  types,  commodity,  mode  of  transportation, 
equipment  load /  empty  or  movement  type. 

•  Ability  to  create  new  routes  by  copying  existing  routes. 

•  Ability  to  define  a  status  for  a  given  route  to  govern  how  the  route  is  used. 

•  Provide  real-time  status  messages  of  rail  activities  to  designated  parties. 

•  Provide  ability  for  personal  to  wirelessly  manage  rail  operations  from  ruggedized  tablets 
and  handheld  devices. 

•  Provide  functionality  to  archive  car  utilization  factors  including:  voyage  ID,  train  ID, 
load-discharge  locations,  total  slots  per  car,  car  load-ability  by  platform,  total  container 
slots  utilized  by  TEU  (twenty  equivalent  units),  total  container  slots  loaded  by  line  of 
business  (LOB),  TEUs  loaded  by  LOB  and  empty  moves. 

10.0  Airlift  Operations 

•  It  is  assumed  that  the  air  traffic  control  features  will  be  handled  outside  of  this 
requirements  specification. 

•  Automate  the  complex  task  of  air  load  planning  with  full  consideration  given  to  all 
individual  aircraft  constraints,  hazardous  cargo  compatibility,  venting  and  shoring 
requirements. 

•  Ability  to  interface  with  air  carriers  to  provide  visibly  of  cargo  movement. 

•  Ability  to  track  flights  and  flights  in-transit,  late  flights  and  route  segments  and  flights 
with  mechanical  problems. 

•  Store  inbound  flight  and  handling  documents  (scanned  images  or  softcopies). 

•  Supports  operational  disruptions  and  flight  monitoring;  ability  to  setup  alert  notifications 
based  upon  events  and  delays. 

•  Maintains  scheduling  information  (considers  schedule  of  the  integrated  system);  creates, 
modifies,  deletes  and  reinstates  seasonal  and  operational  schedules. 

•  Ability  to  monitor  flight  schedules,  AWB  number  and  the  blocking  and  releasing  of 
AWBs  by  customs. 

•  Ability  to  track  actual  flight  performance  to  schedule  and  time  variances. 


21 


Multi-Modal  Terminal  Operating  Software  System 


•  Ability  to  maintain  manufacturers'  specifications  and  loading  constraints  for  aircrafts. 

•  Provide  estimates  of  airlift  requirements  and  develops  initial  load  plans  for  a  given 
equipment  list  given  airlift  parameters,  delivery  method,  aircraft  type,  and  allowable 
cabin  loads. 

•  Ability  to  provide  military  passenger  manifests 

•  Enable  the  ability  to  prioritize  some  or  all  of  the  cargo  and  passengers  (PAX). 

•  Support  airlift  movement  of  the  following  categories  of  cargo:  bulk  and  general  cargo, 
typically  preloaded  on  463L  pallets  and  transportable  by  common  cargo  aircraft; 
oversize,  cargo  requiring  a  C-130  or  larger;  outsize,  cargo  transportable  normally  only  by 
C-5  or  C-17;  rolling  stock,  equipment  that  can  be  driven  or  rolled  directly  into  the  cargo 
compartment;  and  special  items  requiring  particular  preparation  and  handling  procedures. 

•  Provide  entire  management  and  monitoring  of  cargo  consignments,  from  the  moment  a 
shipment  is  delivered  to  the  air  carrier  or  its  ground  handler,  through  to  the  end  of  the 
supply  chain. 

•  Manages  the  ground  handling  activities  associated  with  export  flight  handling,  including 
the  retrieval  of  cargo  from  the  warehouse,  container  and  pallet  build  and  eventual  loading 
on  to  the  aircraft. 

•  Handle  all  activities  associated  with  the  acceptance  of  cargo  and  the  generation  of  the 
relevant  documentation. 

•  Ability  to  create  and  maintain  an  airfield  list  of  aircrafts  (en-route  or  available). 

•  Automatically  accepts  and  processed  freight  waybill  (FWB)  messages,  and  creates  air 
waybill  (AWB)  records. 

•  Prints  air  waybills  in  the  International  Air  Transport  Association  (IATA)  and  Air 
Transport  Association  of  America  (ATAA)  standard  formats. 

•  Allows  air  waybills  to  be  put  on  hold,  and  released,  as  necessary,  and  maintains  a  full 
audit  trail. 

•  Ability  to  view  Load  vs.  Capacity  for  an  aircraft  (real-time),  allowing  updates  to  ensure 
utilization  against  plan. 

•  Provides  airlift  security  measures  and  controls  by  warning  of  any  shipment  holds  or 
interchange  issues. 

•  Support  flight  build-up  preparation  by  showing  the  status  of  flight  load  plans,  and  by 
generating  work  orders  to  ground  handling  crew  and  MHE  as  necessary. 

•  Generates  freight  flight  manifest  (FFMs)  messages  automatically,  and  dispatches  them  to 
all  participating  partners. 

•  Allows  for  flight  capacity  segmentation  and  control  by  stations,  customers,  customer 
groups,  products  and  agreements. 

•  Produces  load  statements  in  order  to  accurately  calculate  the  load  balance  of  the  aircraft. 

•  Provides  instructions/  work  orders  for  placement  of  cargo  in  the  terminal. 

•  Automatically  assigns  storage  location  (according  to  type  of  cargo  and  warehouse 
configuration). 

•  Generates  work  orders  and  assigns  crew  for  build-up  and  breakdown  operations. 

•  Maintains  a  full  audit  trail  of  offloaded  shipments,  and  informs  all  relevant  parties. 

•  Compares  breakdown  documents  with  the  flight  manifests  and  the  warehouse  upon 
completion  of  flight  breakdown,  and  identifies  discrepancies. 

•  Automatically  flags  consignments  that  are  ready  for  collection. 


22 


Multi-Modal  Terminal  Operating  Software  System 


•  Produces  delivery  orders  and  transmits  to  customs,  if  required. 

•  Closes  the  flight  after  departure;  sends  a  departure  status  message  to  the  partners. 

•  Support  reservations,  capacity  control  and  airfield  capacity  management. 

•  Analyzes  and  generates  reports  on  pre  and  post  flight  yield/  load  factor. 

•  Sets  preferred  routes  for  O/D  pairs. 

•  Dynamically  builds  routes  directly  from  flight  schedules  based  on  defined  rules,  type  of 
cargo  and  service  class. 

•  Maintains  connection  time  data  for  stations. 

•  Prepares  flight  release  documentation. 

•  Arrives  shipments  from  a  flight;  generates  arrival  and  transfer  manifests. 

•  Maintains  full  repair  histories  for  each  flight  and  generates  reports. 

•  Ability  for  the  user  to  add  notes  for  various  levels  of  an  airlift  such  as  flight  ID,  pallet, 
container. 

•  Provide  real-time  status  messages  of  airlift  activities  to  designated  parties. 

•  Provide  ability  for  personal  to  wirelessly  manage  airlift  operations  from  ruggedized 
tablets  and  handheld  devices. 

•  Manages  and  controls  bulk  stock  to  support  operations  such  as  fuel  and  deicing  chemicals 
at  the  airfield  and  other  locations 

II.OWarehouse  Operations 

•  Ability  to  configure  warehouse  to  logical  zones/  areas. 

•  Creates  work  orders  for  warehouse  operations. 

•  System  must  permit  frequent  modifications  to  the  warehouse  layout  and  inform 
personnel. 

•  System  must  allow  for  permanent  modifications  (storage  expansion,  acquisition  of 
additional  MHEs,  etc.) 

•  System  must  allow  for  temporary  changes  (out  of  order  equipment,  unavailable  area  of 
the  warehouse  due  repaving,  security,  contamination,  etc.) 

•  System  must  have  the  means  to  set  up  picking  and  placing  rules  throughout  the 
warehouse  (tactical  and  strategic  rules). 

•  Must  be  able  to  search  and  report  on  cargo  and  location. 

•  Ability  to  manually  enter/  update  cargo  information. 

•  Ability  to  provide  a  graphical  view  of  the  physical  location  of  the  cargo. 

•  System  should  provide  an  expert  system  which  will  recommend  storage  locations  and 
activity  based  upon  configurable  rules  for  incoming  cargo. 

•  Fully  manages  cargo  activity,  with  every  aspect  of  the  process  being  recorded  in  audit 
trails. 

•  Manages  all  activities  associated  with  the  receipt  and  release  of  cargo  and  the  generation 
of  the  relevant  documentation.  Reserves  waybill  numbers  from  stock  for  the  shipper  or 
agent  handling  the  cargo. 

•  Ability  to  view  current  and  historical  data  (on  both  electronically  and  manually  generated 
data)  including  associated  notes  and  activity. 

•  Provide  the  ability  to  archive  cargo  inventory  levels  to  support  trend  analysis. 

•  Produces  the  appropriate  dispatch  documentation  and  checks  against  any  related  holds. 
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•  Provide  the  ability  to  attach  and  easily  retrieve  scanned  documents  and  notes  associated 
with  a  particular  piece  of  cargo. 

•  Automatically  create  system  generated  holds  and  permissions  based  on  configurable 
business  rules  such  as  restricted  or  prohibited  commodities,  Homeland  Security,  U.S. 
Customs  or  routing. 

•  Integrated  to  RFID  stationary  and  handheld  readers  to  register  the  received/  released 
cargo  and  provide  visibility  to  terminal  and  relevant  parties. 

•  Communicates  build-up  transactions  to  personnel  through  the  use  of  ruggedized  tablets  or 
handheld  devices  such  as  pre-flight  or  pre-train  manifests,  capture  planned  waybills  and 
generates  a  queue  to  ease  departure  build-up. 

11.1  Load  Optimization 

•  System  must  be  able  to  optimize  container,  trailer  and  pallet  loads. 

•  System  must  accommodate  mixed  sizes  and  weights. 

•  System  must  be  able  to  optimize  on  different  packing  types. 

•  System  must  accommodate  refrigerated  cargo  venting  requirements  and  HAZMAT 
segregation  rules. 

•  System  must  be  able  to  consider  axle  loading/  placement  and  bridge  formulas. 

•  System  must  be  able  to  produce  a  sequential  load  plan. 

12.0  Sealift  Planning 

•  It  is  assumed  that  the  actual  operations  of  a  marine  terminal  will  be  handled  outside 
of  this  requirements  specification.  Stowage  plans,  vessel  details  and  manifests  are 
required  for  inland  port  train  planning. 

•  Receive  status  messages  from  ocean  carrier  on  equipment  to  include  estimated  time  of 
next  key  event. 

•  Ability  to  interface  with  marine  carriers  to  provide  visibly  of  cargo  movement. 

•  Visibility  to  vessel/  voyage  information  including  the  full  vessel  name. 

•  Receive  manifest  information  from  steamship  line  electronically. 

•  Automate  vessel  planning  and  generate  optimized  stow  plans  based  on  configurable  rules 
and  compliance  with  vessel  stowage  and  restrictions;  enables  you  to  stow  one  bay  at  a 
time  or  the  entire  ship  by  combining  stowage  factors  like  type  and  weight  with  yard 
constraints  and  operating  strategy  to  select  the  best  container  to  load  in  real-time. 

•  Ability  to  check  standard  vessel  stability  and  stress  calculations  in  compliance  with 
custom  or  Lloyd’s  lashing  calculations,  as  well  as  Germanischer  Lloyd  Dynamic  Stack 
Weight  requirements. 

•  Provide  graphical  stowage  sequence  planning  for  train  scheduling. 

•  Customs  clearance  requirement  for  port  entry;  ability  to  connect  to  U.S.  Customs 
Automated  Manifest  System. 

13.0  Accounting 

•  Must  exhibit  the  necessary  SOX  controls  through  the  accounting  process. 

•  Maintain  a  centralized  corporate  customer  profiles  module  including  support  for  multiple 
customer  addresses  and  contact  methods. 

•  Must  be  able  to  store/  reference  customer  numbers  as  part  of  a  customer  profile. 
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•  Ability  to  create  repetitive  invoice  and  payment  templates. 

•  Provide  the  ability  for  direct  billing  of  customers  for  waybill,  ground  storage  and 
handling  charges. 

•  Recognizes  various  payment  methods,  and  accept  more  than  one  payment  method  for  a 
single  shipment. 

•  Provide  flexibility  in  generating/  delivering  invoices  electronically. 

•  Provide  flexibility  in  receiving/  processing  invoices  electronically. 

•  The  dispute  process  should  identify  any  invoices  (down  to  the  line  items)  that  are 
disputed;  capture  the  dispute  date  and  reason;  and  the  resolution  date  and  description. 

•  Ability  to  add  additional  charges  to  a  dray  order  e.g.  chassis  add-on’s  (chassis  returns) 
and  double  drays  (e.g.  trucker  is  directed  to  move  container  to  another  facility  because 
rail  billing  is  not  in  place  or  gate  arrival  missed  the  cut-off  time). 

•  Provide  access  to  the  Tariff  Surcharges  used  to  generate  the  customer  invoice;  hazardous, 
peak  season,  fuel  surcharge,  Alameda  Corridor,  Mexico. 

•  Provide  an  audit  trail  of  payment  information  back  to  the  equipment/  cargo  inventory 
activity. 

•  Ability  to  modify  line  items  for  corrections  (pre-billing)  or  adjustments  (post-billing) 
including  creating  a  duplicate  copy  for  editing  purposes  and  retaining  the  original  record 
for  audit  trail  purposes. 

•  The  ability  to  update  the  route  of  an  order  and  assign  financial  responsibility  to  the  carrier 
of  the  transport  legs. 

•  The  ability  to  add  an  accessorial  to  an  order  and  assign  financial  responsibility  to 
vendors,  customers. 

•  Invoicing  of  ground  handling  agents,  carriers  and  stations  for  Charges  Collect  (CC) 
waybills. 

•  Access  to  the  current  and  historical  customer  invoice. 

•  Improve  accuracy  of  billing  calculations  to  reduce  the  number  of  unbilled  charges,  as 
well  as  the  number  of  corrections  necessary  before  invoices  can  be  billed  by  providing 
exception  reports. 

•  Ability  for  the  user  to  add  notes  for  various  levels  of  the  billing  process. 

•  Performs  automatic  rating  based  on  shipment  order  details. 

•  Must  be  able  to  have  configurable  rate  tables  for  freight  rates  and  assessorial  charges. 

•  Ability  to  control  the  rating  hierarchy,  the  order  that  key  information  is  matched  to  the 
shipping  order  to  decide  which  rate  is  applied  to  each  shipping  order  based  on  shipper, 
lane,  commodity,  etc. 

•  The  ability  to  view  and  report  on  current  and  historical  rate  information  using  a  wide 
variety  of  selection  variables  such  as  customer,  beneficial  owner,  origin,  destination, 
equipment  type  and  commodity. 

•  Access  to  view  and  report  on  the  Pricing  Rate  used  to  generate  the  customer  invoice. 

•  Access  to  Per  Diem  Rates/  Revenue  charges  information/  on-terminal  Per  Diem 
exceptions. 

•  Provide  management  oversight  of  billing  and  collections  at  the  Gate  by  providing  an 
Aging  report  for  truckers  with  outstanding  balances. 

•  Ability  to  review,  auto-verify  and  approve  carrier  invoices  prior  to  payment  for  select 
moves,  auto-close  orders  where  applicable. 
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•  Ability  to  print  invoices  individually  or  in  batches  based  on  the  weekly  billing  cycle  or 
user  preference  (i.e.  carrier,  status,  and  trucker). 

•  Need  the  ability  to  short  pay  or  partially  pay  either  on  an  invoice  or  a  balance  due  the 
Railroads. 

•  Provide  the  ability  to  process  freight  payment  (revenue  accounting)  and  process  non¬ 
freight  charges  from  railroads  for  bad  moves,  interchanges,  etc. 

•  Access  to  current  and  historical  payment  information. 

•  Ability  to  accept  billing  on  revenue  empties  with  weights  and  provide  alerts  to  billing  and 
operations  groups. 

•  Ability  to  override  estimated  weight  and  receive  delayed  weights  electronically. 

•  Ability  to  easily  configure  the  start  date  of  the  per  diem  clock  and  other  timed-base  rules 
based  on  configurable  criteria;  need  to  indicate  the  date  on  the  on-line,  printed,  and 
electronic  invoice. 

•  System  should  issue  invoices  for  equipment  returned  to  wrong  location. 

•  Accounting  of  interline  provisions  for  CC  collections  on  behalf  of  other  carriers. 

•  Reconciliation  of  collections  vs.  billings  for  CC  waybills  and  accounting  of  adjustments. 

•  Projected  vs.  actual  revenue  comparison  and  accounting  of  revenue  adjustments. 

•  Export  billing  or  sales  submission  for  specific  regional  areas. 

14.0  Notifications  and  Alerts 

•  Exception  notification  should  be  handled  automatically  by  the  system  by  sending  alerts  to 
downstream  parties  who  need  to  act  on  the  information. 

•  System  must  able  to  generate  notifications  by  various  mediums  such  as  EDI,  FAX,  e- 
mail,  Interactive  Voice  Response  (IVR)  Short  Message  Service  (SMS),  Rich  Site 
Summary  (RSS)  and  display  on  a  web  page. 

•  System  must  allow  for  user  definable  notification  events. 

•  Automatically  selects  desired  party  for  notification  and  method  of  preferred  notification 
based  on  the  customer  profile. 

•  Ability  to  generate  alerts  when  key  operational  and  accounting  process  exceed 
predetermined  time  limits. 

•  Configure  alert  thresholds  for  early/  late  delivery  warnings,  and  capacity  tolerances. 

•  Ability  to  provide  alerts  for  trains/  flights/  vessels  running  behind  schedule  to  customers. 

•  Ability  to  automatically  and  manually  notify  or  re-notify  (notify  party)  by  specific 
container  number  or  numbers  by  O/D  pair,  reference  number,  priority  code;  in  addition  to 
the  ability  to  be  able  to  notify  by  train,  flight  or  vessel. 

•  Maintains  audit  trails  of  all  notification  attempts. 

•  Notify  customers  and  vendors,  providing  inventory  of  out-gated  equipment,  remaining 
free  time,  and  accrued  per-diem  charges. 

•  Tracks  multiple  hazardous  class  codes  and  UN  numbers  per  container  and  alerts  planners 
with  visual  and  audible  warnings  if  planned  moves  generate  segregation  conflicts  in 
accordance  with  IMDG  rules. 

•  Ability  to  systemically  notify  truckers  when  containers  are  available  for  pickup. 

•  The  system  must  alert  users  when  a  vendor  is  within  system-defined  days  of  archived 
contract  expiration  date. 
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•  Ability  to  create  shipping  order  alerts  at  the  container  number  level  or  transport  level  (i.e. 
train,  vessel,  flight). 

•  Need  exception  of  alert  if  an  invoice  is  received  for  car  repair  and  car  history  shows  no 
record  of  car  going  into  damage  status. 

•  Allow  the  system  to  generate  a  notice  to  users  if  a  unit  is  returned  to  a  destination 
different  from  the  destination  shown  on  the  order. 

•  Ability  to  provide  alerts  when  containers  have  exceeded  prescribed  time  at  the  terminals 
and  when  required  dray  information  is  missing. 

•  Ability  to  alert  equipment  group  when  equipment  being  billed  is  not  in  system. 

•  Ability  to  report  on-hire/  off-hire  activity,  track  foreign  containers  and  owners  of  tied 
equipment,  and  track  chassis  under  partner  or  pool  control. 

•  The  ability  to  be  alerted  to  delays  or  non-departures,  grounded  or  adverse  chassis,  bad 
order  containers  and  cars. 

•  Ability  to  provide  alerts  for  equipment/  cargo  place  in  Bad  Order  or  on  a  Hold. 

•  Support  multi-lingual  output. 

15.0  System  Reports 

•  Must  be  able  to  build  and  perform  ad-hoc  or  customer  specific  reports. 

•  Must  provide  a  standard  set  of  core  reports  for  each  functional  area. 

•  Must  be  able  to  send  reports  across  various  mediums  such  as  E-mail,  FAX,  SMS,  RSS 
and  FTP. 

•  Must  be  able  to  save  reports  to  various  formats  such  as  Microsoft  Excel,  CSV,  PDF, 
Microsoft  Word,  Text,  HTML  and  XML. 

•  Ability  to  schedule  reports  for  regular  runs  (e.g.  Yearly,  Quarterly,  Monthly,  Weekly  and 
Daily). 

•  Provide  on-line  displays  with  downloadable  reports,  with  data  drill  down  capability. 

•  Provide  reports  detailing  equipment  inventories  (by  size,  type,  location,  status,  tied  units, 
etc.)  which  provide:  status  model  that  reflect  stages  of  equipment  move  cycle;  number  of 
days  units  are  in  status;  profile  of  equipment  inventory  by  size  (20’,  40’,  45’,  48’,  53’), 
type,  and  subtype. 

•  System  should  report  data  as  to  inventory  of  car  types,  whether  empty  or  loaded,  whether 
damaged,  and  current  car  destination. 

•  Provide  the  ability,  whether  the  container  is  in  truck,  air,  vessel  or  rail  transit  mode  of 
designating  an  expected  destination  and  expected  ETA. 

•  Ability  to  generate  air,  vessel  and  train  reports  by  notify  party,  commodity,  origin  and 
destination. 

•  Provide  exception  handling  reports  for  delayed,  lost,  damaged  or  out-of-route  shipments. 

•  The  ability  to  report  on  the  current  and  historic  status  of  a  piece  of  equipment  such  as 
yard  hostler,  MHE,  yard  hostler,  aircraft,  vessel,  locomotive,  container,  trailer,  tank  car, 
flatcar,  chassis,  reefer. 

•  Ability  to  manage  in-transit  dray  movements  with  online  displays  and  reports  (including 
shipping  order  data)  by;  trucker,  train  id,  vessel  id,  flight  id,  dray  origin,  destination, 
train/  vessel/  flight  cut-off  times. 

•  Provides  exception  reporting  which  highlights  equipment  out-gated  without  information 
required  to  support  expediting  efforts. 
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•  Provides  exception  reporting  which  highlights  equipment  out  past  established  time  limits. 

•  Ability  to  generate  equipment  dwell  reports  to  identify  aging  equipment  by  location,  days 
and  customers. 

•  Need  the  ability  to  report  and  analyze  trends  on  all  equipment  damage  related  costs  for 
truckers  responsible  for  damage. 

•  Provide  displays  and  reports  that  show  inspections  data  including,  a  list  of  equipment  in  a 
particular  location;  list  of  items  requiring  maintenance  (as  specified  by  law  and 
manufacturers  specification);  additional  items  found;  and  generate  line  items. 

•  The  ability  to  automatically  generate  a  report  comparing  days  cars  used  in  service  vs. 
days  out  of  service  as  a  measure  of  performance. 

•  Report  on-hire  and  off  hire  quantities  for  each  location  for  each  month  and  compare  to 
contract  provisions. 

•  Ability  to  support  per-diem  revenue  free-time  exception  reporting. 

•  Report  on  activities  that  relate  to  air,  rail  or  container  yard  (CY)  accessorial  charges  e.g., 
flips,  grounding  storage,  etc. 

•  Report  containers  in-transit  to  destination  on  per-unit  or  aggregated  basis. 

•  Report  containers  and  chassis  inventory  by  owner  or  lessor  codes. 

•  Provide  reports  to  manage  pool  or  shared  chassis  fleets. 

•  Provide  access  to  J-l  and  CY  interchange  documents. 
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16.0  Integration  Requirements 

The  integration  of  both  military  and  commercial  systems  is  critical  to  the  operation  of  the  IP- 
MTOPS  as  required  to  support  the  SCLA  Enterprise  Architecture.  The  figure  below  provides  a 
representation  of  the  systems  potentially  requiring  integration  with  the  overall  IP-MTOPS 
system. 


SM21  Military  Support  Functionality  and  Tentative  Interfaces 


GTN 


I  Integration  Functionality 

Movement  Optimization 

Early  Movement  Requirement  Capture  for 
sustainment  and  force  deployment 

Develop  force  deployment  sequenced 
movement  plan  through  the  region 

Capture  DLA,  Service,  and  Vendor 
Movements 

Develop  modal  alternatives  and  support  modal 
diversions 

Capture  commercial  and  military  track  and 
trace  information 

Develop  force  deployment  movement 
schedules  through  the  region 

|  Process  Control 

Collaboration  Environment 

Provide  automated,  optimization 
workflow  for  modal  diversions  and 
movements  through  the  region 

Provide  coordination  capability  for  movements 
through  the  region 

Provide  exception  management  and  alerts 

Monitor  progress  of  planned  regional 
movements 

Establish  regional  business  processes  for 
military  shipments 

Provide  visibility  of  sustainment,  force 
deployment  and  other  movement  requirements 

Identify  nodal  constraints 

Provide  C2  situational  awareness  and 
actionable  movement  tracking  information 

DTCI 


Figure  5:  Military  System  Interface  Requirements 
The  following  are  the  specific  military  and  commercial  integration  requirements: 


•  Capability  to  easily  interface  bi-directionally  with  various  disparate  external  systems  and 
consume/  produce  various  formats. 

•  Provide  connectivity  to  all  partners  (military,  government  and  commercial)  in  the  global 
supply  chain  (air,  ocean,  drayage,  rail,  freight  forwarders,  customs  brokers,  third  party 
providers,  etc). 

•  Ability  to  transmit  and  receive  acknowledgements  to/  from  the  appropriate  business 
partner. 

•  Access  to  original  transaction  data  both  inbound  and  outbound  transactions. 

•  Allow  on-line  re-processing  of  Soft  Reject  errors. 

•  Must  have  the  ability  to  manually  resolve  missing/  incorrect  data. 
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•  Must  handle  duplicate  events  in  case  of  multiple  sent  by  sources. 

•  Ability  to  monitor  all  integration  electronic  data  channels  and  notify  operations  based 
upon  user-defined  thresholds. 

•  Integrate  with  yard-based  devices  that  provide  audio,  video,  and  data  feeds  via  card  and 
bar  code  readers,  electronic  seal,  ticket  printers,  Radio  Frequency  Identification  (RFID) 
tags,  Automatic  Equipment  Identification  (AEI)  tags,  magnetic  card  readers,  key  pads, 
scale  interfaces,  Optical  Character  Recognition  (OCR)  portals,  license  plate  readers, 
smart  cards  and  driver  ID  scanners. 

•  Ability  to  integrate  with  Biometric  Security  Solutions  such  as  speech  recognition,  thumb 
print  readers,  and  other  biometrics. 

•  Ability  to  integrate  with  the  Integrated  Computerized  Deployment  System  (ICODES). 

•  Ability  to  integrate  with  the  Transportation  Coordinators'-  Automated  Information  for 
Movements  System  Version  II  (TC-AIMS  II). 

•  Ability  to  integrate  with  the  Automated  Air  Load  Planning  System  (AALPS). 

•  Ability  to  integrate  with  the  Global  Freight  Management  (GFM)  System 

•  Ability  to  integrate  the  Global  Air  Transportation  Execution  System  (GATES)  and  the 
Worldwide  Port  System  (WPS). 

•  Ability  to  integrate  with  the  Intelligent  Road/Rail  Information  Server  (IRRIS). 

•  Ability  to  integrate  with  the  future  Defense  Transportation  Coordination  Initiative 
(DTCI) 

•  Ability  to  integrate  to  the  U.S.  Customs  AMS  and  AES  systems. 

•  Ability  to  integrate  to  U.S.  Bank’s  PowerTrack  system  for  billing  and  payment 
processing. 

•  Ability  to  integrate  to  Integrated  Data  Communications  Systems  (IDCS)  for  equipment 
maintenance  and  repair. 

•  Ability  to  integrate  to  REZ- 1  for  equipment  reservation. 

•  Ability  to  integrate  with  real-time  weather  reports  providers. 

•  Must  provide  the  ability  to  produce  and  consume  transportation  standard  ANSI  EDIxl2 
transaction  sets  in  traditional  flat-file  and  corresponding  XML  formats,  including  but  not 
limited  to: 


Air  Shipment  Information 

110  Air  Freight  Details 

Transportation  AEI 

163  Motor  Appointment  Schedule 

Motor  Carrier  Load  Tender 

214  Motor  Carrier  Shipment  Status 

Motor  Carrier  Shipment  Pick-Up  Notification 

217  Motor  Carrier  Loading  Guide 

Ocean  Confirmation 

304  Ocean  Shipping  Instructions 

Customs  Manifest 

310  Ocean  Freight  Receipt 

Ocean  Status 

317  Delivery/Pick-Up  Order 

Terminal  Operations  Activity 

323  Vessel  Schedule 

Vessel  Stow  Plan 

350  Customs  Status 

Rail  Shipment  Information 

410  Rail  Freight  Details 

Rail  Waybill  Interchange 

418  Rail  Consist 

Rail  Switch  List 

440  Shipment  Weights 

Invoice 

820  Payment  Order  Advice 

Application  Advice 

856  Shipment  Notice 
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858  Shipment  Information  943  Warehouse  Shipment  Advice 

944  Warehouse  Receipt  Advice  947  Warehouse  Inventory  Adjustment 

996  File  Transfer  997  Functional  Acknowledgement 


17.0  Technical  Requirements 

•  System  should  have  a  24/7  staffed  Help  Desk  with  appropriate  services  levels  defined. 

•  System  must  be  available  99.9%  (measured  by  month)  which  includes  scheduled  system 
maintenance  windows. 

•  System  must  be  able  to  be  back  on-line  to  operations  within  12  hours  after  a  system 
disaster  has  been  declared  with  minimal  data  loss. 

•  System  should  have  appropriate  service  levels  defined  with  the  hosting  provider. 

•  System  must  have  pro-active  monitoring  with  automatic  notifications  sent  to  the  technical 
support  staff  warning  of  any  potential  system  issue. 

•  Operational  customer  require  access  to  systems  outside  of  their  offices  (while  on  ramps 
and  the  yards)  to  update  information  as  well  as  receive  system  updates/  alerts. 

•  Data  retention  should  include  the  current  year  plus  two  previous  years  for  logistics 
analysis. 

•  Provide  a  customer  centric  web  portal  which  will  provide  visibility  of  shipments. 

•  System  must  promote  a  highly  scalable  fault  tolerant  hardware  and  software  architecture. 

•  Provide  authentication  and  authorization  for  access  to  applications  and  data. 

•  System  must  support  role-based  security  and  access  and  promote  a  uniform  enterprise 
security  model. 

•  Controls  access  to  functions  and  inventories  by  user  ID  (e.g.  any  customer  specific  data 
may  be  accessed  only  by  customer-authorized  users) 

•  Provides  for  classes  of  security  so  that  a  user  may  be  assigned  to  a  class,  inheriting  the 
security  associated  with  that  class. 

•  Requires  each  user  to  have  a  unique  user  ID. 

•  Bars  concurrent  use  of  the  same  user  ID. 

•  Requires  each  user  to  have  a  password  and  requires  passwords  to  be  changed  on  a 
scheduled  frequency  as  defined  by  the  system. 

•  Logs  user  off  system  after  a  defined  period  of  inactivity. 

•  Suspends  user  ID  after  repeated  unsuccessful  log-on  attempts. 

•  Provides  method  for  tracking  user  access  and  system  activity. 

•  Provides  method  for  identifying  the  user  ID  and  last  revision  date  for  each  activity. 

•  Minimize  the  number  of  times  that  a  user  needs  to  authenticate  themselves  to  systems. 

•  All  data  deemed  to  be  sensitive  in  nature  shall  be  encrypted. 

•  Provide  secure  transport  of  data  while  interacting  with  external  systems. 

•  Support  service-oriented  solutions;  flexible  and  easily  adaptable  to  business  change. 

•  Separate  presentation,  business  logic  and  data  access  layers  clearly  defined  within  an 
application. 

•  Support  a  reference  architecture  that  utilizes  established  design  patterns. 

•  Standardize  user  interfaces  independent  of  platform. 

•  Use  uniform  messaging  and  data  format  protocols  (i.e.  XML) 
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•  Integration  of  applications  to  utilize  synchronous  or  asynchronous  messaging  as 
appropriate  in  the  solution  context  and  preference  will  be  given  to  asynchronous 
communication  whenever  loose  coupling  of  applications  is  desired. 

•  Create  shared,  common  and  encapsulated  business  interfaces. 

•  Use  a  content  management  system  to  access  and  manage  unstructured  data. 

•  Use  a  document  management  system  to  access  and  manage  various  scanned  documents. 

•  Utilize  an  external  business  rules  engine  to  provide  global  and  regional  rule-based 
decision  support. 

•  Apply  data  transformation  rules  only  once  within  the  data  architecture. 

•  Automate  end-to-end  monitoring  of  system  processes. 

•  Provide  electronic  means  for  data  input  and  data  transfer  to  reduce  dependence  on  paper- 
based  input. 


18.0  Summary 

The  development  of  IP-MTOPS  will  be  a  joint  effort  between  SM21,  SCLA,  and  the  City  of 
Victorville.  The  resulting  SOA  based  software  system  will  support  the  functions  of  a  dual-use 
multi-modal  inland  port.  IP-MTOPS  will  be  developed  to  support  the  refinement  and  integration 
of  the  functional  requirements  independently  developed  by  the  joint  partners.  Since  the  facility 
is  intended  for  dual-use,  SM21  will  ensure  that  DoD  stakeholder  requirements  are  integrated  to 
support  the  JDDE10. 


10  See  footnote  2.  The  JDDSP  is  the  military  component  of  the  dual-use  IP-MTOPS. 
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APPENDIX  A:  SYSTEM  INFORMATION  SCENERIOS 

The  following  system  information  scenarios  in  which  the  SOLA  Enterprise  is  expected  to 
participate  are  provided  as  reference  to  this  document  for  procurement  actions  and  should  not  be 
considered  all-inclusive. 

Ocean  Import 

•  The  Port  and  Terminal  are  pre-noticed  of  arriving  inbound  cargo  via  the  vessel  manifest. 
U.S.  Customs  provides  Custom  clearance  status. 

Transaction  sets: 

o  Booking  Information,  EDI  301; 
o  Vessel  Manifest,  EDI  309; 
o  Bill  of  Lading,  EDI  304; 
o  Forwarding  Instructions,  EDI  304; 
o  Customs  Clearance  Status,  EDI  350; 
o  Vessel  Stowage  Plan,  EDI  324. 

•  The  Port  provides  status  updates  as  cargo  is  landed. 

Transaction  sets: 

o  Status  Information  EDI  304. 

•  For  efficient  handling  (ramp,  de-ramping)  the  Port  unitizes/containerizes  break-bulk 
cargo  to  suitable  equipment. 

•  Automatic  matching  of  arriving  equipment  and  pre-advised  information  and  system 
suggests  terminal  yard  parking  after  equipment  is  identified  based  on: 

o  Non-matching  equipment  marked  for  quarantined/  investigation; 
o  Customs  Hold/Release  status; 

o  Special  Handling  considerations  (refrigerated,  HAZMAT,  etc.); 
o  Pre-advised  forwarding  instructions; 
o  Foreign  Trade  Zone  (FTZ)  Customs  status. 

Transaction  sets: 

o  Terminal  Operations  Activity  EDI  322. 

Ocean  Export 

•  Before  the  cargo  can  be  accepted  the  shipment  details  is  arranged  between  the  exporting 
ocean  carrier  and  shipper. 

Transaction  sets: 

o  Booking  Information,  EDI  301; 
o  Bill  of  Lading,  EDI  304; 
o  Forwarding  Instructions,  EDI  304; 
o  Customs  Clearance  Status,  EDI  350; 
o  Vessel  Stowage  Plan,  EDI  324. 

•  Based  on  stowage  plans,  booking  information  and  local  yard  situation,  the  Port  plans  the 
train  loading  sequence  and  sends  that  to  the  Terminal. 

•  Terminal  system  verify  load  ordering  against: 

o  Equipment  and  pre-advised  information; 
o  Customs  hold/release  status; 

o  Special  Handling  considerations  (refrigerated,  HAZMAT,  etc.). 
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•  Terminal  loads  the  train  according  to  port  ordering. 

Transaction  sets: 

o  Terminal  Operations  Activity,  EDI  322. 

Highway  Arrival 

•  The  Terminal  is  receives  shipment  information  from  the  Consignor. 

Transaction  sets: 

o  Load  Tender,  EDI  204; 
o  Transportation  Status,  EDI  214. 

•  Trucker  presents  himself  and  delivery  documents  at  the  gate. 

•  Documents  are  matched  against  system. 

•  Trucker  is  directed  to  parking  area  or  unloading  dock  at  terminal. 

•  Equipment/cargo  is  received. 

Transaction  sets: 

o  Terminal  Operations  Activity,  EDI  322. 

•  Terminal  sends  arrival  notice  to  related  parties. 

Highway  Departure 

•  Terminal  receives  pickup  instructions  from  the  Consignee. 

Transaction  sets: 

o  Load  Tender,  EDI  204; 
o  Response  to  a  Load  Tender,  EDI  990; 
o  Transportation  Status,  EDI  214. 

•  Trucker  books  pickup  appointment  (Web  Interface  or  EDI). 

•  Trucker  presents  himself,  delivery  documents  and  pickup  reference  at  the  gate. 

•  Documents  are  matched  against  system. 

•  Equipment/  cargo  is  released. 

Transaction  sets: 

o  Terminal  Operations  Activity,  EDI  322. 

•  Terminal  sends  release  notice  to  related  parties. 

Inbound  Rail 

•  The  Terminal  receives  Shipment  information  from  the  Rail  Carrier  or  Consignor. 
Transaction  sets: 

o  Bill  of  Lading,  EDI  404; 
o  Rail  Waybill,  EDI  417. 

•  The  transport  status  and  progress  is  reported  via  status  messages. 

Transaction  sets: 

o  Terminal  Operations  Activity,  EDI  322; 
o  Car  Location  Message,  NITL  CLM. 

•  Rail  Carrier  delivers  railcars  to  Terminal. 

Transaction  sets: 

o  Rail  Consist,  EDI  418. 

•  Arriving  equipment  is  automatically  matched  against  the  pre-advised  information. 

•  System  suggests  yard  parking  after  equipment  is  identified  based  on: 
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o  Non-matching  equipment  is  marked  quarantined  for  investigation; 
o  Customs  hold/release  status  is  recorded  against  equipment  if  export; 
o  Special  handling  considerations  (Refrigerated,  HAZMAT,  etc.); 
o  Pre-advised  forwarding  instructions  from  Ocean  Carrier. 
Transaction  sets: 

o  Terminal  Operations  Activity,  EDI  322. 

•  Terminal  sends  arrival  notice  to  related  parties. 

Outbound  Rail 

•  Consignor  (Terminal  or  Freight  Agent)  issues  Shipment  to  Rail  Carrier. 
Transaction  sets: 

o  Bill  of  Lading,  EDI  404. 

•  Rail  Carrier  accepts  shipment  and  generates  a  Rail  Waybill. 

Transaction  sets: 

o  Rail  Waybill,  EDI  417. 

•  Terminal  plans  the  train  loading  and  generates  work  orders. 

•  Rail  Carrier  releases  empty  railcars  Terminal. 

•  Terminal  loads  railcars. 

Transaction  sets: 

o  Terminal  Operations  Activity,  EDI  322. 

•  Rail  Carrier  pulls  railcars  from  Terminal. 

Transaction  sets: 

o  Rail  Consist,  EDI  418. 
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Figure  6:  Inbound  to  Port 
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APPENDIX  B:  GLOSSARY 

Terminology 

Definition 

AAR 

Association  of  American  Railroads.  The  central  coordinating  and  research  agency 
of  the  American  railway  industry.  This  agency  deals  with  matters  of  common 
concern  in  the  whole  field  of  railroading  from  operations  to  public  relations. 

ACCESSORIAL 

CHARGE 

A  service  in  addition  to  the  line  haul  service,  usually  at  an  added  expense.  Charges 
incurred  to  provide  additional  services  at  the  time  of  pick-up  or  delivery  of  the 
container.  These  might  include  driver  assist  in  load  or  unload,  driver  waiting  time  to 
load  or  unload  past  free-time  provision  of  the  tariff,  equipment  rental  (fork  lift), 
blocking  or  bracing,  additional  stop-off  charges,  container  charges  etc. 

ACL 

Allowable  Cargo  Load.  The  amount  of  cargo  and  passengers,  determined  by 
weight,  cubic  displacement,  and  distance  to  be  flown,  that  may  be  transported  by 
specified  aircraft. 

ALL  WATER 

SERVICE 

(AWS)  Ocean  service  from  the  Far  East  to  the  East  Coast  of  the  U.S.  via  the 
Panama  Canal. 

BACK  HAUL 

The  movement  of  freight  (or  empty  equipment)  back  to  the  point  of  origin  in  a  lane 
of  little  or  no  demand  for  the  service. 

BAD  ORDER 

Something  is  wrong  with  the  equipment. 

BENEFICIAL  OWNER 

The  entity  that  actual  has  title  to  the  cargo  being  shipped. 

BILL  OF  LADING 

A  document  that  establishes  a  contract  between  a  shipper  and  a  transportation 
company  that  moves  freight  between  specified  points  for  a  specified  charge.  Usually 
prepared  by  the  shipper  on  forms  issued  by  the  carrier,  it  serves  as  a  document  of 
title,  a  contract  of  carriage  and  a  receipt  for  the  goods. 

BLOCKED  TRAIN 

Railcars  grouped  in  a  train  by  destination  so  that  segments  (blocks)  can  be 
uncoupled  and  routed  to  different  destinations  as  the  train  moves  through  various 
junctions.  Eliminates  the  need  to  break  up  a  train  and  sort  individual  railcars  at 
junctions. 

BOC 

Beneficial  Owner  of  the  Cargo.  The  entity  that  actually  owns  (has  title  to)  the  goods. 
See  Beneficial  Owner. 

BOOKING 

Recording  arrangements  for  the  movement  of  goods  by  ocean  or  stack  train. 

BRC 

Billing  Repair  Card.  A  detailed  record  of  repairs  performed  in  accordance  with 
AAR  Rule  83. 

BUNDLED  RATES 

Rates  that  include  all  costs  in  one  charge. 

CAPACITY 

PLANNING 

A  plan  which  measures  and  analyzes  the  ratio  of  units  required  versus  units 
available  for  a  given  time  period.  The  direct  planning  of  specific  units  to  specific 
loads. 

CARRIER 

An  individual,  company  or  corporation  engaged  in  transporting  goods. 

CBP 

U.S.  Customs  and  Border  Protection  of  the  Department  of  Homeland  Security. 

CHASSIS 

The  wheels  and  frame  assembly  that  supports  the  container. 

CLAIM 

A  demand  made  upon  a  carrier  for  payment  on  account  of  loss  sustained  through  its 
negligence  or  accidental  damage  while  under  the  carrier’s  authority. 
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CLM 

Car  Location  Movement.  A  railroad  record  movement  of  a  load. 

COFC 

Container  on  flatcar.  A  container  that  moves  on  a  flatcar  without  a  chassis. 

COMMODITY 

The  description  of  the  actual  goods  being  shipped. 

COMMON  CARRIER 

A  transportation  company  operating  under  a  Certificate  of  Convenience  and 
Necessity;  provides  service  to  the  general  public  at  published  rates. 

CONSIGNEE 

The  receiver  of  the  goods  being  shipped. 

CONSIGNOR 

A  person  or  company  shown  on  the  bill  of  lading  as  the  shipper. 

CONTAINER 

A  piece  of  equipment  that  has  a  removable  chassis.  Usually  used  in  ocean  carriage 
or  on  stack  trains.  Comes  in  various  sizes:  20’,  40’,  45’,  48’  and  53’. 

CONTAINER  POOL 

An  agreement  between  parties  that  allows  the  efficient  use  and  supply  of  containers. 
A  common  supply  of  containers  available  to  the  shipper  as  required. 

CONVENTIONAL 

SERVICE 

Containers  moving  on  conventional  flatcars  (COFC/TOFC)  owned  by  rail  carriers. 

CROSS-TOWN 

A  truck  movement  between  one  railroad  intermodal  ramp  and  another.  Utilized 
either  for  speed  or  because  the  two  railroads  don’t  have  a  connection. 

CUBE  OUT 

When  a  container  has  reached  its  volumetric  capacity  before  it  reaches  its  permitted 
weight  limit. 

CUT-OFF  TIME 

The  latest  time  that  a  container  may  be  delivered  to  a  rail  ramp  or  vessel  in  order  to 
be  accepted  for  the  scheduled  departure  time. 

CY 

Container  Yard.  A  place  where  chassis  and  container  equipment  is  stored. 

DEMURRAGE 

See  Per  Diem 

DERAMPED 

A  trailer/container  that  has  been  taken  off  a  railcar. 

DESTINATION 

The  place  where  the  carrier  releases  the  cargo  to  the  consignee  or  his  agent. 

DETENTION 

A  charge  by  a  vendor  after  a  specific  time  has  passed. 

DISPATCH 

Information  given  to  the  drayman  that  is  picking  up  a  load  at  origin  or  delivering  it 
at  destination. 

DIVERSION 

A  change  made  in  the  route  of  a  shipment  in  transit 

DOOR-TO-DOOR 

Through  transportation  of  a  container  and  its  contents  from  consignor  to  consignee 

DOUBLE  STACK 

Refers  to  placing  one  container  on  top  of  another  container  in  a  double  stack  railcar 
for  onward  movement. 

DRAYAGE 

The  truck  portion  of  an  intermodal  movement. 

DRAYMAN 

A  carrier  who  provides  pick-up  and  deliveries  via  truck  to  and  from  the  rail  yard. 

DRIVER  ASISST 

When  the  driver  is  required  to  load  or  unload  a  shipment. 

DROP 

The  driver  leaves  the  trailer  at  the  customer’s  facility  and  picks  it  up  after  it  is 
loaded  or  unloaded. 

DRY  FREIGHT 

Dry  cargo  not  requiring  temperature  control  protection 

DST 

Double  Stack  Train.  Refers  to  the  practice  of  placing  one  container  on  top  of  another 
in  a  special  railcar  for  movement.  See  double  stack. 
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EARLY  WARNING 

A  directive  issued  by  the  AAR  for  interchange  freight  cars  having  mechanical  or 
potential  safety  problems. 

EDI 

Electronic  Data  Interchange;  The  exchange  of  information  via  computer. 

EIR 

Equipment  Interchange  Receipt.  A  form  used  by  parties  delivering  or  receiving 
containers  or  container  equipment.  Used  for  equipment  control  and  damage  liability 
purposes.  Synonymous  with  TIR  (Trailer  Interchange  Receipt) 

EMPTY  REPO 

Empty  repositioning.  The  movement  of  empty  containers  by  rail  or  truck  to  meet 
service  requirements  elsewhere. 

EMPTY  SLOT 

An  available  loading  position  on  a  stack  car  created  when  a  container  isn’t  loaded  to 
an  available  position.  Also  known  as  a  vacant  slot. 

EN-ROUTE 

In  transit  to  destination. 

ETA 

Estimated  Time  of  Arrival  of  a  load. 

FAK 

Freight  All  Kinds;  A  generic  term  for  any  kind  of  freight. 

FCL 

Full  Container  Load 

FEU 

Forty- foot  Equivalent  Unit. 

FLATCAR 

A  railcar,  which  a  trailer/container  is  placed  on  to  move  via  the  railroad.  A  car 
without  roof  or  walls. 

FLIP 

When  a  container  is  picked  up  off  of  the  ground  and  mounted  on  a  chassis  for  street 
or  highway  transport. 

FRA 

Federal  Railroad  Administration.  The  FRA  deals  specifically  with  transportation 
policy  as  it  affects  the  nation’s  railroads  and  is  responsible  for  enforcement  of  rail 
safety  laws. 

FREE  TIME 

The  amount  of  time  allowed  by  the  carriers  for  the  loading  or  unloading  of  freight 
before  charges  begin  to  accrue. 

FREIGHT 

Refers  to  either  the  cargo  carried  or  the  charges  assessed  for  the  carriage  of  the 
cargo. 

FREIGHT  BILL 

A  document  issued  by  the  carrier  based  on  the  bill  of  lading  and  other  information; 
used  to  account  for  a  shipment  operationally,  statistically,  and  financially. 

FREIGHT 

FORWARDER 

A  company  that  arranges  for  the  movement  of  import  and  export  shipments.  Also 
prepares  all  necessary  U.S.  Customs  documentation. 

FTZ 

Foreign-Trade  Zone.  A  restricted-access  site,  authorized  by  the  FTZ  Board  and 
supervised  by  CBP  (19  CFR  146)  where  companies  can  use  special  Customs 
procedures  prior  to  entry  for  consumption.  Zones  are  located  in  or  adjacent  to  a  CBP 
port  of  entry  and  operated  pursuant  to  public  utility  principles  under  the  sponsorship 
of  a  corporation  granted  authority  by  the  Board  pursuant  to  the  Foreign-Trade  Zones 
Act  (19  USC  81a-81u)  and  regulations  (15  CFR  Part  400). 

GATE 

A  point  at  an  intermodal  terminal  where  a  clerk  checks  in  and  out  all  containers  and 
trailer.  All  reservations  and  paperwork  are  checked  at  the  gatehouse. 

GENSET 

Generator  used  to  regulate  temperature  in  a  reefer  container;  can  be  run  on  its  own 
power  or  plugs  provided  at  the  storage  area. 

GROSS  WEIGHT 

Combined  weight  of  cargo  and  container  ready  for  shipment. 
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HAZMAT 

Hazardous  Material.  Product  that  is  determined  to  be  harmful  and  requires  special 
handling  as  set  forth  by  government  agencies  and  the  intermodal  companies. 

HOSTLER 

An  individual  employed  to  move  containers  and  trailers  within  a  terminal  or 
warehouse  yard  area. 

IANA 

Intermodal  Association  of  North  America.  An  industry  trade  association 
representing  the  combined  interests  of  intermodal  freight  transportation  companies. 

ICC 

Interstate  Commerce  Commission.  A  federal  regulatory  agency  that  governed  over 
the  rules  and  regulations  of  the  railroading  industry.  The  ICC  Termination  Act  of 
1995  ended  this  regulatory  agency.  Most  responsibilities  were  transferred  to  the 
Surface  Transportation  Board. 

IMC 

Intermodal  Marketing  Company.  An  intermediary  in  the  movement  of  intermodal 
shipments.  See  Third  Party. 

IN-BOND 

A  shipment  that  is  moving  but  has  not  cleared  U.S.  Customs.  The  clearing  of  U.S. 
Customs  will  occur  at  destination. 

INBOUND 

Cargo  moving  from  a  rail  terminal  towards  its  destination.  Generally  used  for  cargo 
coming  off  a  train  and  heading  for  final  delivery  to  consignee. 

IN-GATE 

The  transaction  or  interchange  that  occurs  at  the  time  a  container  is  received  by  a 
rail  terminal,  container  yard,  or  water  terminal  from  another  carrier. 

INTERCHANGE 

The  exchange  of  railcars  between  connecting  railroads. 

INTERLINE 

Between  two  or  more  transportation  companies. 

IPI 

Inland  Point  Intermodal.  A  shipment  booked  and  moved  from  foreign  origin  port  to 
U.S.  inland  destination  for  one  quoted  charge  by  the  steamship  line. 

ISO 

International  Organization  for  Standardization 

J-l 

A  report  filled  out  during  the  in-gate  and  out-gate  process.  The  J-l  details  damage  to 
the  unit,  container  information,  shipping  information,  drayman  involved  and  time  of 
in-gate/  out-gate. 

JOB  CODE 

A  4  digit  number  that  identifies  the  inspection,  repair,  and/  or  testing  performed,  or 
the  car  component  applied  or  removed. 

LADING 

Refers  to  the  freight  shipped;  the  contents  of  a  shipment. 

LIFT 

The  process  of  moving  a  container  or  trailer  to  and  or  from  a  rail  car. 

LINE  HAUL 

The  movement  of  freight  via  railroad  from  one  city  to  another. 

LIVE  LOAD 

The  driver  stays  with  a  load  while  it  is  being  loaded  or  unloaded. 

LOCAL  CARGO 

Cargo  that  is  booked  from  a  foreign  port  to  a  U.S.  port  with  no  inland  movement  of 
the  freight  by  the  steamship  line. 

LTL 

Less  Than  Truckload.  A  shipment  that  would  not  by  itself  fill  the  truck  to  capacity 
by  weight  or  volume. 

M&R 

Maintenance  and  Repair.  The  process  of  maintaining  equipment  in  good  repair  and 
serviceability. 

MARINE  TERMINAL 

The  facility  where  cargo  is  discharged  from  and  loaded  to  the  ocean  vessel. 

MHE 

Materials-Handling  Equipment.  Mechanical  devices  for  handling  cargo. 
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NET  WEIGHT 

Weight  of  the  cargo  alone,  without  any  immediate  wrappings. 

NOTIFY  PARTY 

The  party  that  is  notified  at  the  time  a  container  or  trailer  is  grounded  from  a  train. 
Most  notify  parties  are  draymen. 

NVOCC 

Non  Vessel  Operating  Common  Carrier.  A  company  that  buys  wholesale  space  on 
steamship  lines  and  resells  the  space  to  individual  shippers  at  a  profit. 

OCP  CARGO 

Overland  Common  Point.  Refers  to  cargo  that  is  handled  by  the  steamship  line  only 
to  a  U.S.  port  of  entry.  The  shipper  or  consignee  then  plans  to  move  the  cargo  inland 
(east  of  the  Rockies)  at  their  expense. 

OD  PAIR 

Origin  /  destination  locations  identified  in  a  tariff  rate  structure. 

ON-DOCK 

Refers  to  the  process  whereby  cargo  from  the  ocean  vessel  is  loaded  to  railcars 
within  the  marine  terminal. 

ORIGIN 

Location  where  shipment  begins  its  movement  at  cargos  expense. 

OUTBOUND 

Cargo  moving  from  a  shipper  to  rail  ramp.  Generally  refers  to  cargo  going  onto  a 
stack  or  conventional  train. 

OUT-GATE 

The  transaction  or  interchange  that  occurs  at  the  time  a  container  is  delivered  from  a 
rail  terminal,  CY,  or  water  terminal  to  another  carrier. 

OVER-THE-ROAD 

(OTR) 

An  all  truck  freight  shipment,  used  in  lieu  of  rail  service,  at  a  premium  charge. 

OWNER  CODE 
(SCAC) 

Standard  Carrier  Abbreviation  Code  identifying  the  carrier  -  drayman,  steamship 
line  etc. 

PALLET 

A  wooden,  paper  or  plastic  platform  usually  with  a  top  and  bottom,  on  which 
packaged  goods  are  placed  to  facilitate  movement  by  some  type  of  freight  handling 
equipment. 

PER  DIEM 

Additional  charges  to  the  shipper  or  consignee  for  a  carrier’s  equipment  past  the  free 
time  provisions  of  the  equipment  interchange  contract  while  the  equipment  remains 
in  the  possession  of  the  shipper  or  consignee. 

PICK-UP 

The  act  of  calling  for  freight  by  truck  at  the  consignors  shipping  platform. 

PICK-UP 

APPOINTMENT 

Scheduled  time  for  pick-up  or  loading  of  a  container  from  a  shipper  or  consignee. 

PICK-UP  NUMBER 

A  secure  number  provided  to  parties  listed  on  the  waybill.  It  allows  only  those 
parties  to  receive  a  container  in  order  to  out-gate  from  ramp  facilities. 

POD 

Proof  of  Delivery.  A  form  signed  by  the  consignee,  proving  the  load  has  been 
delivered. 

POOL 

A  group  of  equipment  at  a  customer’s  facility  for  them  to  load  at  their  convenience. 

PRENOTE 

Information  sent  to  the  delivering  carrier,  telling  where,  when  and  how  to  deliver  a 
load. 

RAIL  GROUNDING 

The  time  that  the  container  was  discharged  (grounded)  from  the  train. 

RAIL  NOTIFICATION 

Notification  to  the  Notify  Party  that  the  container  has  been  discharged  from  the  train 
and  is  available  for  pick-up. 

RAIL  RAMP 

The  location  where  the  draymen  pick  up  and  deliver  loads  to  the  railroad,  and  where 
trains  are  loaded  or  discharged. 
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RAMP 

A  technical  rail  ramp  not  serviced  by  an  actual  train. 

RAMPED 

A  trailer/container  that  has  been  placed  on  a  railcar. 

REVENUE  LOAD 

A  load  of  freight  for  which  freight  charges  are  applied. 

REVENUE  WAYBILL 

A  waybill  showing  the  amount  of  charges  due  on  a  shipment. 

RULE  11 

A  railroad  accounting  term  which  refers  to  a  customer  shipping  their  freight  "pre¬ 
paid"  to  an  intermediate  point  and  "collect"  beyond  that  intermediate  point  to  the 
final  destination. 

SCAC 

See  Owner  Code. 

SEAL 

Something  applied  to  the  outside  of  equipment  doors  after  loading  to  assure  the  load 
has  not  been  tampered  with. 

SERVICE  FAILURE 

When  the  actual  delivery  exceeds  the  customer’s  expectations  by  a  specific  amount 
of  time. 

SHIPMENT 

The  tender  of  one  lot  of  cargo  at  one  time  from  one  shipper  at  one  location  to  one 
consignee  at  one  destination,  on  one  bill  of  lading. 

SHIPPER 

The  actual  party  tendering  a  load  of  freight. 

SHIPPING  ORDER 

Instructions  of  shipper  to  a  carrier  for  forwarding  of  goods. 

SHORING 

A  system  of  horizontal  and/or  inclined  structural  members  fastened  to  the  piles  of  a 
bent,  group  or  row  to  increase  stability  by  resisting  or  distributing  lateral  forces  to 
the  structure.  Similar  to  bracing. 

SLOT  UTILIZATION 

The  method  of  utilizing  every  space  available  on  a  double  stack  car.  A  slot  includes 
the  space  above  a  container  when  another  container  can  be  double-stacked.  A  five 
platform  double  stack  car  has  10  slots  available  for  loading.  If  all  10  slots  are 
loaded,  you  have  100%  slot  utilization. 

SPOTTING 

Placing  a  container  where  required  to  be  loaded  or  unloaded 

STACK  CAR 

An  articulated  five  or  three-platform  railcar  that  allows  containers  to  be  double 
stacked. 

STACK  TRAIN 

A  dedicated  train  that  hauls  containers  stacked  two  high. 

STAY  WITH 

Type  of  drayman  service  whereby  the  driver  remains  with  the  freight  while  the 
shipper  or  consignee  loads  or  unloads. 

STCC 

“Standard  Transportation  Commodity  Code.  A  method  of  identifying  products  or 
commodities  using  standardized  numeric  codes. 

STORAGE  CHARGES 

See  Demurrage/  Per  Diem. 

SURCHARGE 

An  extra  or  additional  charge. 

TARE  WEIGHT 

The  weight  of  packing  material,  or  in  railcar  or  container  shipments,  the  weight  of 
the  empty  railcar  or  empty  container. 

TARIFF 

A  publication  setting  forth  the  charges,  rates  and  rules  for  transportation  companies. 

TENDER 

The  offer  of  goods  for  transportation  or  the  offer  to  place  cars  or  containers  for 
loading  or  unloading. 

TERMINAL 

An  assigned  area  in  which  containers  are  prepared  for  loading  onto  a  train  or  are 
stored  after  discharge  from  a  train. 
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TERMINAL  CHARGE 

A  charge  made  for  services  performed  in  a  carrier’s  terminal  area. 

TEU 

Twenty-foot  Equivalent  Unit.  A  standard  container  size  used  for  comparative 
measuring  purposes.  Normally  applied  to  containers  used  by  steamship  lines  (20,  40 
and  45  foot  containers) 

THIRD  PARTY 

Refers  to  an  intermediary,  which  arranges  for  the  movement  of  intermodal 
shipments. 

THIRD  PARTY 
INTERNATIONAL 

An  ocean  shipping  company 

TOFC 

Trailer  On  Flat  Car.  A  trailer  that  moves  on  a  flat  car  with  the  chassis  attached. 

TRAILER 

A  freight  vehicle  equipped  with  a  permanent  wheel  assembly  and  a  device  for 
attaching  to  a  tractor  for  movement. 

TRAILER 

INTERCHANGE 

Transfer  of  a  trailer  and  lading  from  one  carrier  to  another. 

TRAIN  ID 

A  system  to  identify  the  trains  origin  and  destination  points,  the  day  of  the  week  for 
departure  and  the  week  of  the  year  it  moved. 

TRANS  PACIFIC 

Import/export  water  service  to  and  from  the  West  Coast  ports  to  and  from  Far  East 
ports. 

TRANSIT  TIME 

The  actual  amount  of  time  for  a  load  to  move  from  point  of  origin  to  delivery  at 
destination. 

TRANSLOAD 

The  transferring  of  product  from  one  piece  of  equipment  to  another. 

UMLER 

Universal  Machine  Language  Equipment  Register.  A  computer  readable  file  of  vital 
statistics  for  each  railroad  car  in  service.  It  applies  to  all  railroads,  types  of  cars,  and 
data  processing  machines. 

UNBUNDLED 

A  product  that  will  have  separate  charges  for  each  activity  accorded  to  the  shipment 

UNIT  TRAIN 

A  train  of  a  specified  number  of  railcars,  which  remain  as  a  unit  for  a  designated 
destination  or  until  a  change  in  routing  is  made. 

WASTE  CUBE 

A  container  with  empty  space.  May  result  when  the  weight  load  is  reached  before 
the  volumetric  limit. 

WAYBILL 

A  document  prepared  by  a  transportation  line  at  the  point  of  a  shipment;  shows  the 
point  of  origin,  destination,  route,  consignor,  consignee,  description  of  shipment  and 
amount  charged  for  the  transportation  service.  A  waybill  is  forwarded  with  the 
shipment  or  sent  by  mail  to  the  agent  at  the  transfer  point  or  waybill  destination. 
Unlike  a  bill  of  lading,  a  waybill  is  not  a  document  of  title. 

WHY  MADE  CODE 

Numeric  code  used  to  designate  the  reason  repairs  or  services  were  made  or 
performed. 

YARD 

A  classification,  storage  or  switching  area. 
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APPENDIX  C:  REFERENCES 

1 .  Advent  Inc,  Advent  Terminal  Operating  System  (TOS),  www. adventinc . com 

2.  Canadian  National,  Intermodal  Terminal  Management  System  (ITMS),  www.cn.ca 

3.  Cargo  Data  Management  Corp,  Station  Track  II,  www.cargodata.com 

4.  Central  Systems  &  Automation  Ltd,  Autostore  Container  Terminal  Management  System 
(CTMS),  www.central-systems.co.uk 

5.  CMC  Limited,  Marine  Container  Handling  System,  www.cmcltd.com 

6.  COSMOS,  COSMOS  Terminal  Systems,  www.cosmos.be 

7.  CSX,  Intermodal  Terminal  Operations  System  (ITOPS),  www.csxi.com 

8.  Embarcadero  Systems  Corporation,  Computer  Automated  Terminal  Operation  System 
(CATOS);  Premier  Appointment  System  (PAS),  www.esvstem.com 

9.  eOPS  Inc,  eTERM,  www.etermsys.com 

10.  Erl,  Thomas.  Service-Oriented  Architecture:  Concepts,  Technology,  and  Design,  Upper 
Saddle  River,  NJ:  Prentice  Hall  Professional  Technical  Reference,  2005 

11.  Hamburg  Port  Consulting,  Container  Terminal  Information  System  (CTIS), 
www.hamburgportconsulting.de 

12.  IBS  Software  Services,  iLogistics,  www.ibsplc.com 

13.  IntelliTrans  LLC,  Global  Visibility  Platform  (GVP);  Material  Management  System 
(M2S),  www.intellitrans.com 

14.  Kale  Consultants  Ltd,  MERCURY,  www.kaleconsultants.com 

15.  Maher  Terminals  Logistic  Systems,  MTLS  Container  Terminal  Management  System, 
www.mtls.co 

16.  Mercator,  Chameleon,  www.mercator.com 

17.  Navis,  SPARCS  Terminal  Operating  System,  www.navis.com 

18.  Optimization  Alternatives,  Optimization  Alternatives'  Strategic  Intermodal  Scheduler 
(OASIS);  Yard  Hawk,  www.oax.com 

19.  Sabre  Airline  Solutions,  CargoMax,  www.sabreairlinesolutions.com 

20.  Softship,  Terminal  Management  System  (TMS),  www.softship.com 

21.  Virtual  Yard  Management  Inc.,  KT3  Yard  Management  System  (YMS),  www.vyminc.com 
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